Any Cables Monthly #9
April, 2023
This issue marks the beginning of the new AnyCable era! We finally reached the point where we go beyond being just an Action Cable replacement but a standalone tool with its own unique features.
Highlights
AnyCable v1.4 first release candidate is out!
The long-awaited AnyCable release with consistency features is just around the corner. Give it a try, and share your feedback. Together we can make real-time applications better!
Videos
The pitfalls of realtime-ification
To learn more about the problems we try to solve with AnyCable v1.4, check out this one-year-old talk by Vladimir Dementyev.
Releases
AnyCable website got a major upgrade!
The list of changes and additions is huge (compared to v4.x): new operations, #stream_from, #broadcast_later, and many more.
A new library to work with WebSockets for Rust from the Deno team. Should we rewrite AnyCable in Rust 🤔
The frame of curiosity: GPT → SSE
ChatGPT is the hottest topic on the Internet these days. How can we justify mentioning it in our newsletter? By looking under the hood of the OpenAI chat user interface.
When you communicate with ChatGPT, you can see response text appearing in chunks (just like someone’s typing in real-time). If you open a browser’s dev console and sneak into the Network tab, you can see that the response is coming from the /conversation endpoint, and it’s just a single request whose response type is text/event-stream:
That means that the real-timeness of the chat is provided by Server-Sent Events (SSE). SSE is a mechanism to stream response from a server to a client instead of buffering and flushing it as a whole.
Unlike WebSockets, SSE is part of the HTTP protocol. A client makes a regular HTTP request, and a server writes event chunks in response using the specified format:
data: Server-Sent Events (SSE) is a web technology\n\n
data: that allows a web page to receive automatic updates from a server via a long-lived HTTP connection.\n\n
The “\n\n” acts as a delimiter to separate events. The connection stays open until the server or the client closes it on their end.
Although the SSE technology was introduced before WebSockets (~2009 vs. ~2011), SSE didn’t become the primary tool to add live updates to web applications. Partially due to worse browser support (Internet Explorer never supported SSE) and partially due to other limitations, such as being uni-directional (only a server can send events, but not a client) and text-based.
Today, browser support is no longer a problem, and the benefits of being HTTP-based may overcome the limitations. Which benefits? First of all, simplicity of implementation. All you need is direct access to the connection’s underlying I/O to write data in chunks. Here is, for example, how you can implement SSE with pure Rack:
In Rails, we have ActionController::Live::SSE mixin to send streaming updates from a controller’s action.
So, should you consider using SSE for your next project instead of WebSockets? Try discussing this question with ChatGPT 🙂. I had an interesting conversation that ended with the following statement:
Stay human! See you next month!