AnyCable VS rubocop

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.

gem "rubocop" - https://github.com/rubocop/rubocop | Set up code guidelines for your dev team, I recommend using whatever Standard recommends.

I believe if you use the `||` operator instead of `or`, then things just work out fine. I agree it is really annoying. But I am pretty sure if you use a tool like RuboCop https://github.com/rubocop/rubocop (a static code analysis tool) then it will catch bugs like this. Note that I am not recommending Ruby. But in my experience if you want to work with a language and it has a community style guide and a linter that enforces it, it will save me some heartache.

Adopt some sort of consistent formatting. Your top-level module starts off indented, seems like wasted space. May I suggest RuboCop?

By default, out of the box, RuboCop comes with a default set of pre-configured rules. The documentation will tell you Rubocop's default rules.

RuboCop is a Ruby static code analyzer (a.k.a. linter) and code formatter. Out of the box it will enforce many of the guidelines outlined in the community Ruby Style Guide. Apart from reporting the problems discovered in your code, RuboCop can also automatically fix many of them for you.

But I will encourage you to adopt Rubocop to enforce the style you want, so that if others want to contribute, they can write with spaces and then run rubocop -a and end up with the styling you prefer. Tabs indentation support was added a couple of years back: https://github.com/rubocop/rubocop/pull/7867

In my last job I encountered my first Rails codebase ever (mostly REST APIs but a few server-rendered views as well). After the initial chaotic impression of the codebase (it was a startup after all) with all the Rails magic on top, I really fell in love with the framework after a more experienced Rails dev introduced a few key conventions and helpful libraries to the codebase.

Out of those, I’d at least add the RuboCop [1] linter and the BetterSpecs [2] guidelines to this list. Both helped tremendously in eliminating bikeshedding in the team and freeing up brainpower to solve actual problems. The first one helped me learn intricacies of Ruby bit by bit right in my IDE and the latter guided us to write tests in a style that’s easy to maintain and trust.

[1] https://github.com/rubocop/rubocop

[2] https://www.betterspecs.org/

RuboCop had a setting for this but it was removed for Ruby 3 because there are valid reasons to pass a hash into a method, and linting it might break code. Here is the issue referencing the commits where it was removed, if you ever need to do this again you could just find an earlier commit.