Any Cables Monthly #8
🌸 Welcome to the first spring issue of our newsletter, teeming with fresh insights on AnyCable, Hanami, and serverless WebSockets. Dive in and let your curiosity bloom!
(P.S. This intro was crafted by yours truly, GPT-4 🤖)
Highlights
AnyCable off Rails: connecting Twilio streams with Hanami
This article covers a lot of things: consuming Twilio Media streams with AnyCable, enhancing Hanami with Phlex, Vite, and CableReady. Don’t be overwhelmed, read responsibly 🙂
Videos
Flying multi-regionally with NATS
Releases
The demo application used in AnyCasts goes public. Check out the code of the past and future episodes!
The release makes it possible to provide custom channel resolution logic (we use it in the AnyCable Hanami example mentioned above).
The xk6-cable repository now also hosts JS helpers to simplify writing scenarios for Action Cable / AnyCable applications.
The frame of curiosity: serverless WebSockets
Wait, what? Serverless WebSockets? Is that a thing? Yes, it is.
Serverless functions have been around for enough time to become mundane. The concept (for end users) is pretty simple: you write a function, upload it and trigger it via HTTP API or some internal platform-specific mechanism. Every execution is independent and isolated, just like a standalone process. (Just like a good old CGI but at the cloud level).
WebSockets are different. They’re long-lived; they’re stateful. We can not process WebSocket connections with regular serverless functions. First, serverless functions usually have execution time limits too small to serve persistent connections. Secondly, WebSocket connections are typically idle for most of their lifetime—it’s a waste of precious (and pricey) serverless resources.
To overcome these limitations, serverless platforms provide a separate layer to handle connections and only delegate events to serverless functions. Doesn’t it sound familiar? It’s the same principle that AnyCable uses to offload WebSockets. Technically, AnyCable-Go plays the same role as AWS API Gateway, for example.
Routing WebSocket events to serverless functions works great. The most complicated part of serverless WebSockets is broadcasting messages to connected clients. In other words, the pub/sub component must be implemented from scratch*.
It’s questionable whether such architecture scales despite being serverless. Probably, a mix of serverful and serverless would be a better option here.
Still, I’m very excited by the ongoing research on serverless WebSockets in the Ruby community. Check out this issue in the Lamby repository for more resources on the topic.
* AWS AppSync can be integrated with another AWS product, EventsBridge, to build a pub/sub layer, but it’s bound to GraphQL protocol.