Any Cables Monthly #11
Dear Reader, we're excited to offer you an exclusive first look at the latest release of AnyCable. We're taking the reliability of WebSockets to unparalleled heights! ⚡️
Plus, don’t miss our curated selection of news and insights from the world of real-time web.
Highlights
No more candidates: AnyCable v1.4 is here!
But 🤫 This is our secret. Official announcements are coming next week; we’re working hard on them—there is a bunch of cool stuff happening in v1.4! Here is a quick overview:
Reliable streams—go from at-most-once delivery to at-least-once and beyond to ensure that no data slip through the cracks of the fragile real-time connectivity.
HTTP over RPC, because not everyone needs or loves gRPC, and supports it (I’m looking at you, Heroku 😼). Oh, and we even got a cute little “deploy to Heroku” button:
Hotwire (Turbo Streams) applications without Rails and even Ruby are welcome!
Long polling support is added for applications working behind corporate firewalls and proxies 🧱, which is often the case for our e-health customers 👩⚕️.
News
A new exciting feature is coming to turbo—View Transitions API integration. You can see this feature in action on RubyVideo.dev (use Chrome or Edge—browser support is still lagging behind).
Podcasts
Giant Robots #482: Evil Martians with Irina Nazarova
The conversation between Victoria Guido from Thoughtbot and Irina Nazarova from Evil Martians (and AnyCable) explores how consulting and product development mutually enhance each other, as feedback from consulting clients often triggers open-source projects that can later be commercialized (of course, Ira is using AnyCable as an example 😉).
Releases
Turbo Train is an alternative Rails backend for Turbo Streams that uses third-party pub/sub services (Mercure and Fastly Fanout) for delivering messages to clients. What’s noticeable is that this train bets on Server-Sent Events (SSE) as an underlying transport mechanism, not WebSockets.
The frame of curiosity: the transport problem 🚠
No, this post is not about traffic in your favorite city. I want to talk about transports powering real-time features in web applications.
Real-time web is old. Like, really old. Back in the days, we used browser plugins or extensions to bring real-time communication over raw sockets or proprietary protocols (such as RTMP in Flash—that’s when I started building real-time web applications back in 2009).
Native support for real-time in browsers was limited to different polling techniques: persistent links were emulated via ever-retrying regular HTTP calls pinging server and asking “Is there something for me?” instead of waiting for a push.
The funny thing is that even today we still use long-polling as a fallback transport. Yes, we just added long-polling support to AnyCable Pro. I can hear your “WHY???”. Let me answer this screaming question in the end of this post. Now, let’s move on with the transports evolution.
Server-Sent Events were introduced in 2019. We talked about them in one of our previous issues (#9). Let’s recall that although they were introduced as a part of the HTTP spec, it became widely adopted (i.e., by all major browsers) only recently. For example, there is still no support by Internet Explorer. Nowadays, however SSE are getting more and more popular (see, for example, turbo-train project we mentioned above). There are several things that make SSE attractive to developers:
Simplicity. You need just a couple of lines of code to create a reliable link to receive updates.
Reliability. Browsers take care of reconnecting and even requesting missed messages (though this requires server-side support) via the special
Last-Event-Idheader.
Let’s imagine how an Action Cable SSE interface may look like:
const url ='/sse-cable?channel=ChatChannel&roomId=42'
const eventSource = new EventSource(url)
eventSource.onmessage = event => {
const message = JSON.parse(event.data)
console.log('Message: ' + message.from + ' - ' + message.text)
}That’s it! Want to see this API live? Stay tuned for the upcoming AnyCable updates 😉.
A recent post from Ably gives a great overview of SSE in 2023. Check it if you want to learn more. Now, let’s move on to the next candidate—WebSockets.
WebSockets were introduced in 2011. It took a while for them to get the traction and become the top-1 technology to build real-time applications. First, browser support was lagging (though we could use WebSockets through Flash polyfills). Then, proxy servers and firewalls were struggling with recognizing such a strange HTTP traffic (yeah, that probably wasn’t a good idea to make WebSockets wrapped into HTTP connections). The second problem was almost solved by enforcing encrypted (TLS) connections. Why “almost”? Because some corporate standards require employees to install their root certificate to effectively sniff traffic and… block WebSockets!
(Another good thing about SSE is that it’s a true HTTP, so it’s less likely to be blocked by paranoid androids.)
Now, imagine this situation. You have clients seating inside very strict corporate networks and still using IE10. What’s your option? HTTP streaming!
Yes, there is one more way to stream data via HTTP—HTTP streaming. This term usually imply performing requests with the Transfer-Encoding: chunked, so that a server may write response in chunks and the client may read it as a stream (without waiting for the response to complete). Modern browsers provide APIs to turn response body into a readable stream and consume chunks as they’re written. Although these APIs are still too modern for IE, it is rumored that HTTP streaming can be implemented using some hacks and tribal knowledge (and spirit helpers, I think).
In Ruby world, the most popular project using HTTP streaming is message_bus, which powers many Discourse installations across the world.
Coming back to the original question: why did we decide to add long polling support to AnyCable? It was IE10+ in requirements, that limited our options. HTTP streaming would require a decent amount of work on the client-side. Long polling is easier to implement and it has more potential use cases—making an HTTP POST request is a no-brainer in any programming language or on any platform.
We’re not going to stop here. AnyCable must prove the “any” in the name. For example, we plan to add SSE support soon. And we’re looking forward into the future, as well.
A new transport is here to conquer the world of real-time web—WebTransport. WebTransport is a new protocol built on top of HTTP/3. It provides means for bi-directional communication over reliable or unreliable channels. Will it replace WebSockets or not? We’ll see. It’s definitely worth giving a try.
Stay tuned! Avoid traffic congestions!