Any Cables Monthly #23: it's a Rails, Rails World!
September, 2024
Hey there! We’re just back from the Rails World conference in Toronto and ready to share some news with you (not only from the world of Rails, of course).
News
Another major milestone for Rails is just around the corner. The new version’s slogan is “No PaaS required”: the framework provides all you need to deploy applications on any machine in minutes without any additional infrastructure dependencies. One of the missing pieces in Rails 7 was a Redis requirement for Action Cable. Now, we have Solid Cable, which uses a database as a pub/sub backend. See Releases below for more Rails 8 related updates.
OpenAI just introduced a new API—the Realtime API (beta) that allows you to communicate with LLMs via text and audio over WebSockets!
Which amazing new feature are you going to build with it?
Events
Evolution of real-time and AnyCable Pro (EuRuKo 2024)
Take a quick look back (and forward) and see how the world of realtime web evolved over the past 10 years from the perspective of Team AnyCable.
Releases
The work on the new Action Cable architecture (see issue #17) is almost done. What’s left is to do some field tests before we can merge this work into Rails. For that, we’ve extracted the functionality into a standalone gem, actioncable-next, that you can install into your existing Rails (7+) application to give it a try. See also the actioncable-next-playground showcasing some example use cases for the new architecture.
GraphQL AnyCable no longer requires using Redis pub/sub adapter for AnyCable. You can use any AnyCable broadcasting adapter in your application and configure Redis to store subscriptions separately!
Frame of curiosity: Weird realtime transport: BroadcastChannel
Earlier this year, we’ve started exploring the possibility of leveraging WebAssembly powers for Rails applications. Yes, Rails in the browser! That might sound… strange?.. but consider it a research project that could bring results far beyond the goals we try achieve today.
It might not be clear from the first sight, what running a web application within the boundaries of the browser may have in common with realtime technologies. But the thing is: even if you have just a single instance of the application running for a single client, your application UX might still rely on live update functionality.
We cannot run a true WebSocket server in the browser; long-lived, streaming connections (e.g., SSE) to wasmified applications are also hardly possible. All we have is the browser, or a bit broader, a JavaScript runtime.
The good thing about full-featured realtime frameworks (like Action Cable or AnyCable) compared to pure transport-level libraries (hey, Socket.io) is that the actual real-time logic at both server and client ends do not depend on the actual transport implementation. Hence, all we need is to find a new transport that would fit the constraints.
One of the in-browser transports we successfully implemented is the BroadcastChannel-driven one. If you want to learn more, check out our Rails on Wasm handbook.
Keep it weird 👻