Any Cables Monthly #24: AnyCable speaking!
Any Cables Monthly #24: AnyCable speaking!
October-November, 2024
With all the fall conferences, we can hardly keep pace with time and publish the updates as soon as yet another month ends. So, this issue covers October and ½ of November, and the last issue of the year is scheduled for somewhere around Christmas and New Year. Relax and enjoy the magical season ⛄️!
Highlights
Hey, AnyCable speaking! Needing help with a Twilio-OpenAI connection?
AnyCable meets Twilio again! This time, we demonstrate how to build conversational voice assistants using OpenAI Realtime, Twilio Media Streams, and AnyCable as a middleman between all this machinery and your backend application. Check it out!
Talks
Evolution of real-time and AnyCable Pro (Rocky Mountain Ruby 2024)
How to migrate a chat service used by 300,000 people from Firebase Realtime Database to Action Cable (Kaigi on Rails 2024)
The slides are in Japanese, though it might be a bit tricky to understanding; but just the title and the diagram above should at least make you curious 🙂.
Podcasts
Remoty Ruby: Solid Cable with Nick Pezza
The conversations goes into the deeps of Action Cable implementation, thundering herd problem for WebSockets, and benchmarking WebSockets.
Releases
This tiny release introduces one long-awaited feature: TOML configuration for the server. Given the huge number of configuration parameters and static natures of the most of them, having a file-based config is definitely a DX improvement. It’s especially useful for local development: just drop a file and don’t teach the team which options to provide and how to keep them in sync. As a bonus, anycable-rails now generates anycable.toml for you during the setup.
Frame of curiosity: Durable Objects and the consistency conundrum
Recently, I've been at a tech conference where a developer asked: "Should we use Durable Objects to build collaborative UX?" This led me down a fascinating rabbit hole of distributed systems trade-offs that I'd like to share with you.
Durable Objects make an intriguing promise: globally consistent, single-threaded objects distributed across Cloudflare's edge network. Like having a tiny, dedicated server for each piece of state. Sounds perfect for real-time applications, right? Well, it depends.
Consider collaborative editing. With Durable Objects, every user action is processed strictly in order by a single object, which eliminates potential edit collisions. However, this comes with two significant trade-offs:
First, when users are geographically distributed, latency will depend on how close each person is to the physical location of the object. Cloudflare picks this location. As a result, if you are further away from the rest of your team, your UI can be sluggish and unresponsive, while everyone else’s experience is perfect.
Second, during network hiccups, Cloudflare might need to recreate your object elsewhere to maintain consistency. Your application freezes rather than risks inconsistency. Classic CAP theorem: choosing consistency over availability.
There's an old distributed system saying: "You can't not have distributed state, you can only choose how to distribute it." Durable Objects chooses strong consistency over availability—often not ideal for real-time collaboration. Sometimes, being "eventually right" beats being "immediately frozen."
What's your take? Have you faced similar architectural decisions? Share your thoughts—respond to this email, or leave a comment on substack.