Any Cables Monthly #7
February, 2023
The last winter month was full of updates (and snow here in New York ❄️): AnyCable development is back on track, Stimulus Reflex team is just a few steps from releasing long-awaited releases.
Highlights
Videos
RubyConf Australia ended just a few weeks ago, but we can already enjoy the videos. We suggest starting with the “Asynchronous Rails” talk by Samuel Williams to learn more about Threads and Fibers and the progress made with the latter ones in Ruby and Rails recently.
Building Stream Processing Applications with Ruby & Meroxa
RubyConf videos also became publicly available in Feb. The real-time topic wasn’t widely represented (if it was at all). We picked the video on real-time data processing just because of the slide shown above: it demonstrates the list of problems related to any real-time system.
Articles
Real-time magic, no elixirs: optimizing Sera with AnyCable
Evil Martians share the story of helping Sera Systems to migrate from an ad-hoc Elixir real-time service to AnyCable.
You Don't Need Rails to Start Using Hotwire
The article explains how to use Turbo Drive and Turbo Frames without any backend (just a web server to serve static HTML). The next step could be adding AnyCable with its signed streams feature to bring real-time features (without bringing Rails 😉).
Releases
cable_ready · 5.0.0.pre10 & stimulus_reflex · 3.5.0.pre10
We’ve been waiting for CableReady 5 and StimulusReflex 3.5 for a long time. With the recently published pre-releases, they finally have finally reached the finish line.
This release adds a couple of new features: channel.receiveAll(timeout) message.__timeout__. Here is an example benchmark scenario.
A little Action Cable developer helper, ACLI (Action Cable CLI), got a minor update with fixes and better debugging capabilities.
@anycable/turbo-stream · 0.3.1
This release brings connected state support to the source element (recently added to turbo-rails).
The frame of curiosity: beyond web cables
Usually, when we talk about real-time applications, we consider a real user of meat and bones to be the client (the one who initiates a connection). However, the world of real-time web is not limited to humans and Martians. Let’s consider a couple of examples.
What is the oldest over-the-wire real-time communication technology? Telephony. Sometimes we need to integrate old-school phone calls to our web applications. For example, we can build robots responding to voice calls or performing some kind of analysis in real-time. That’s where we need some kind of cable to connect, say, a Rails application with a Nokia 3310.
Twilio, for instance, provides a feature called Media Streams. It’s nothing but a WebSocket-hook for voice calls: whenever a call starts, a WebSocket connection is established to your server, and audio packets are sent through it. You can read phone calls in your app and write commands and responses back.
WebSocket-hooks are still rather rare; ordinary webhooks still rule. But there are situations where webhooks don’t work. For example, when a receiver is behind a NAT/firewall or doesn’t have a public/known IP address at all. For example, electric vehicle (EV) chargers.
EV chargers communicate with a central management system over the Internet. The central system's main responsibilities are processing payments and monitoring chargers. Although most of the communication has the charger-to-system direction, there are some use cases when an action must be initiated from the central system side (for example, toggling the availability of the station or starting a charger session if a driver struggles to do that). Thus, we need a way to push commands to chargers. Here come WebSockets, again.
Many EV charging systems rely on closed proprietary protocols (e.g., Tesla), but there is an open-source movement in this field, too. The Open Charge Point Protocol (OCPP) has been developed to standardize charger-to-server communication, so you can build a web application to control compatible EV chargers by implementing this protocol.
Now imagine the following scenario:
A driver struggles to start a charging session and calls tech support over the phone.
A Twilio Stream is created and sends audio over a WebSocket to some cable application, where we perform text-to-speech analysis and identify the driver request (“please, start my charging session”).
An OCPP command is sent over a WebSocket connection to the charger to start a remote transaction.
And what if I tell you that you can implement the following scenario with Rails and AnyCable? Stay tuned for updates!