Any Cables Monthly #20
April-May, 2024 AnyCable/Thruster
Hey everyone! Looks like we’re turning into a bi-monthly newsletter 😁 Luckily, the spring conference season is over and we have no excuses (and no alarms🚨) to continue keeping radio silence.
Posts
Experimenting with real-time data compression by simulating a football match events
Our friends from Centrifugo recently released the delta compression feature for WebSocket clients, which they explore in this post using a football (or soccer) game live translation as an example use case. Great post and a very good example given that Euro 2024 is just around the corner (Forza Italia 🇮🇹!)
(If you want to dig deeper into the delta compression topic, check out our Issue #15, where we talked about the diffing problem for real-time streams in the context of LiveView and Turbo Streams).
LiveVoice shares how they use AnyCable
Read the story by Sebastian Poell, AnyCable user and LiveVoice co-founder, on how they use AnyCable to power real-time interpretation for guided tours. What I like most about this case study is that it’s full of technical details and real-time tips (i.e., not a marketing BS).
Releases
Thruster and AnyCable walk into a bar… Yes, this is a mix of two to make you run one process less! Check out this demo PR (also including a freshly released capybara-thruster to speed-up your system tests).
@anycable/turbo-stream · 0.7.0
This release introduces a new configuration option—delayedUnsubscribe. This setting aims to solve a common problem (or peculiarity): avoid instant subscribe-unsubscribe commands in case the new page HTML contains the same <turbo-stream-source> elements (so our server does not process useless commands and our clients do not miss messages in-between).
This release fixes a bunch of TypeScript inconsistencies.
These tiny releases makes Server-Sent Events via AnyCable as powerful as WebSockets by porting all the missing features (signed streams, history offset, etc.). We also added raw mode for SSE clients to receive only data messages ignoring all protocol events.
Frame of curiosity: to thrust or not to thrust?
Thruster is going to be a part of Rails 8 distribution. Well, not a anymore (and I’m glad we didn’t publish this issue a month ago 😁). Nevertheless, it is still worth discussing this potential change in the way we serve our Rails applications locally and in production.
Thruster is a standalone proxy server which aims to stand in front of your bin/rails s and do some routine work: serve static assets, terminate SSL, etc. The concept of having a non-Ruby web server is not new to Rails (remember Passenger?), so why do we cycle back to it again? Because, it’s 2024, and not using HTTP/2+ and manually generating SSL certificates (when deploying on bare metal) is too old school even for Rails developers. DX (Developer eXperience) is what engineers care about today (if you don’t—please, start right now). And Thruster aimed to provide a decent one (“Heroku-like”) for one-person Rails installations. “Aimed”, because it seems that Kamal 2 Proxy is going to replace it for production deployments. We’ll see this September.
In any case, Rails 8 will have an official reverse proxy, whether you need or not (--skip-kamal). Of course, there are alternatives starting from good old Nginx (or its Unit version) and continuing with Caddy, a modern and extensible application server. Let’s pay a bit more attention to the latter one.
As I said, Caddy is modern: supports HTTP/2 (and HTTP/3, if you wondered) and it manages SSL certificates with a matter of a configuration change (even for localhost). What’s more important, it has a pluggable architecture, and you can extend it via modules. There are some built-in modules (mostly typical reverse proxy features, such as redirect rules, etc.) and plenty of custom extensions (GeoIP decoding, caching, and many more). And of course, you can write your own!
Of course, the cherry on the top is the fact that Caddy has been running tons of applications for years. It’s a robust piece of software, so why can’t Rails developers benefit from using it like some PHP devs do via FrankenPHP? Why can’t we extrapolate the success of using Caddy for Rails applications deployment from Hatchbox to everywhere else, including our local environments?
These questions have been bothering me since the very introduction of Thruster. Surely, greenfield Rails apps would benefit from Thruster/Kamal Proxy right away; it’s simple and it works (though it will take quite a bit of time to stabilize and mature); we can even extend it like we did with AnyCable Thruster; but we’ll inevitably hit its limits; and I’m afraid sooner than later.
That’s why we (some mysterious “we” for now) started an R&D project on building a smart reverse proxy for Rails applications on top of Caddy, covering use cases not only observed once but by many diverse applications and teams. And we want to make useful, Rails-friendly extensions for HTTP available out of the box: AnyCable, imgproxy, Wafris, etc.
If you like this idea, please share your suggestions on what might be nice to have in such a Rails-oriented application server.