AnyCable VS WebPush

The AnyCable WebSocket Server was created to combine the beauty of Action Cable with the performance benefits gained from Golang. AnyCable handles WebSockets on a different server called AnyCable-Go, effectively reducing the burden on your primary web application.

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.

So there is a gem webpush for adding webpush functionality into your Rails App. We had implementation for webpush already with the model named as Push_subscription. Basically for each webpush notification there will be a record in the database which on subscribing triggered the user browser and he can see the notification in the web.

As one of the top contributors to the open source zaru/webpush gem, I am happy to see that Web Push and the Push API will be supported soon by iOS.