AnyCable VS litestack

LiteCable is tailored for vertical scaling by a tight integration of components. If you extract maximum performance from the SQLite engine, the limits of this approach are pushed a lot further. Once you observe that your latencies start to explode, though, I would suggest researching options like AnyCable, which inherently provide better strategies for horizontal scaling.

Here we'll deploy Anycable wih MRSK.

So far, everything is working great with our new LambdaCable gem. Eventually it will be a drop-in adapter for ActionCable and join the ranks of other popular alternatives like AnyCable. To bring the project to completion faster, I needed feedback loops that were much faster than deploying code to the cloud. I needed a development proxy! One where my Rails application would receive events from both Lambda's Function URLs and the WebSocket events from API Gateway. Illustrated below with a demo video.

AnyCable v1.3 has been just released. The major highlights are:

I've been using this technique for a long time for gems development—to speed up CI RuboCop runs (by installing only the linter dependencies). Here is my typical rubocop.gemfile:

It does, but the precompiled binaries are only for < 3.1: https://rubygems.org/gems/grpc/versions/1.43.1-x86-linux

Action cable is probably what you're looking for. If you start having performance issues, AnyCable is a more performatic option that requires almost no changes in your ruby code.

I decided to give it a try for the AnyCable demo application, which requires deploying not only a Rails app, but also additional services for AnyCable.

I think what's being talked about here is the back end implementation for ActionCable. By default it uses ruby threads to push over open web sockets. There's at least one production quality drop in implementation (https://anycable.io/) that address the default scalability issues you'll have with ActionCable. The async support would seem to allow one to go much further with default rails before needing to move to something more performant.

The benchmarks for LiteCache are impressive, with a small caveat. While LiteCache outperforms a local Redis installation for every read operation, it seems like there's still room for improvement, especially for large write payloads.

Luckily, the official LiteStack benchmarks include measurements for LiteCable against Redis, which I am going to quote here.

Let's quickly look into how LiteJob uses SQLite to implement a job queueing system. In essence, the class Litequeue interfaces with the SQLite queue table. This table's columns, like id, name, fire_at, value, and created_at, store and manage job details.

Next, we install LiteStack using the shipped generator:

Related: I wrote a piece last week on deploying Rails apps to production on Fly.io at https://fly.io/ruby-dispatch/sqlite-and-rails-in-production/

The work that’s made this possible is:

1. Litestack - https://github.com/oldmoe/litestack

2. Fly.io’s work on the dockerfile-rails generator detecting Sqlite and Litestack in a Rails project, then setting up sane defaults for where that data is stored and persisted in production. This is all done behind the scenes with no intervention required from the person deploying.

3. Servers are overall faster and more powerful

I hope more Rails hosts make it easier and safer to deploy Sqlite to production. It will lower costs and reduce complexity for folks deploying apps.

Didn't know that one! The litestack.gemspec shows it's a wrapper around the sqlite3 gem. So, not really comparable...

I’m working on this for Rails apps at https://github.com/oldmoe/litestack/pull/12

The idea is that people with small-to-medium size Rails Turbo apps should be able to deploy them without needing Redis or Postgres.

I’ve gotten as far as deploying this stack _without_ LiteFS and it works great. The only downside is the application queues requests on deploy, but for some smaller apps it’s acceptable to have the client wait for a few seconds while the app restarts.

When I get that PR merged I’ll write about how it works on Fly and publish it to https://fly.io/ruby-dispatch/.

Rails is the way to go. The productivity of the Ruby language is insane. It's battle tested for decades and you can easily scale your prototype.

If you want a simple app served on a single host you can try LiteStack [0] so you don't need a Redis/Postgres/Sidekiq instance, just SQLite.

Laravel is also good if you like PHP language.

[0] https://github.com/oldmoe/litestack