Highlights

AnyCable 1.6.9: Durable Streams support

The headliner: AnyCable now speaks Durable Streams—an open HTTP protocol for reliable, resumable data streaming from ElectricSQL.

We announced the gradual adoption of the protocol in the AnyCable, Rails, and the pitfalls of LLM-streaming post back in December. Well, “gradual” happened faster than expected—with AnyCable v1.6.9, the read side is done. Your clients can now consume AnyCable streams using any Durable Streams-compatible client. You still publish via the AnyCable API (broadcasting), but on the read side, it’s an open standard. No vendor lock-in, no proprietary protocol required.

Other highlights from the release:

• New REST API for publishing broadcasts and querying presence from any HTTP client—no SDK required (docs)

• Pusher Get Channel Users API to simplify the migration to AnyCable (docs).

News

An update on The end of Heroku

Sad (but kinda expected) news: Heroku is turning on maintenance mode (read: “we’re gradually sunsetting our operations”). If you’re using it and have been expecting to rely on it in the mid- to long-term, you need to start looking for alternatives.

Today, there are plenty of PaaS platforms offering a Heroku-like experience (I’m pretty sure we’ll continue using this term even when Heroku is no more). Self-hosting is also not rocket science anymore; the variety ranges from Kamal to Kubernetes kits.

We decided to check the distribution of deployment platforms among AnyCable users (based on the anonymized telemetry we collect) and got the following results:

Out of the identified platforms (you see the “None” at the bottom—it’s everything from self-hosted and local runs to k8s clusters), Heroku is 2nd, with ECS/Fargate as the leader. Not suggesting anything, just sharing our data. (But you need help in picking and implementing the escape strategy, Evil Martians are here to help.)

Durable Streams on Electric Cloud

Since we covered the original announcement in #32, ElectricSQL shipped fast: from v0.1.0 (NPM) on Dec 23 to the hosted cloud along with v0.2.0 on Jan 22. The new version also comes with the Idempotent Producer specification—don’t even try to publish your message twice! We, Team AnyCable, are glad to be in the company of early adopters of this new, exciting technology. Are you durable streaming yet?

Valkey 9.0: innovation, features, and improvements

The announcement is not fresh, but we decided that it deserves more attention. Why? First of all, Valkey has finally caught up on the Redis features released in 7.4 (right after the change in the Redis licensing policy, and thus not available to other cloud providers). For example, the family of Hash field expiration commands (HEXPIRE et al) is now supported, making Valkey compatible with AnyCable Presence implementation.

Videos

Real-time Collaboration with Rails, AnyCable and Yjs (JP Camara @ SF Ruby Conference)

All 32 talks from SF Ruby Conference 2025 are published on sfruby.com/talks. Check them all out!

Posts

Rails Apps on V8 Isolates

Can you imagine running a Rails app on V8 (JS runtime) for serverless sake? No need to imagine, Sam Ruby is already bringing this to life. Realtime-wise, check out the chat demo: Action Cable backed by Broadcast Channel (do you remember we shared the same idea when talked about Rails on Wasm in #23).

Releases

anycable · 1.6.9

We’ve already mentioned Durable Streams and REST API additions. Another noticeable addition is a mTLS support for Redis (or Valkey).

anycable-laravel · 0.3.0

We changed the way the server is configured when running the php artisan anycable:server command to use Laravel configuration. (Thanks for the feedback from our AnyCable Laravel early adopters!).

loro · 1.10

Loro is a Y.js alternative built in Rust by an independent team. Loro produces cleaner merges thanks to the Fugue algorithm. It also keeps full editing history by default—you get Git-like time travel without bolting on extra storage. Bindings exist for JS/WASM, Swift, Python, and React Native, plus ProseMirror and CodeMirror integrations.

centrifugo · 6.6.0

The release notes are read as a year-end recap: v6, async consumers, server-side publication filtering, WebSocket over HTTP/2, C# SDK, 7k+ installations.

livewire · 4.0.0

Livewire 4 makes building reactive web applications (in PHP) with no JavaScript even simpler: now, you can mix PHP, view templates, styles and JavaScript (“no” doesn’t mean “never”) in a single file! (I have strong MXML vibes 😁.)

Frame of curiosity: Who’s next? Pusher?

Heroku has become synonymous with the “git push” deployment experience. It’s been the default for Ruby on Rails applications for years. And now what? It’s over.

What other PaaS services will repeat the fate of Heroku? Who pioneered a field, set the standard, and is now struggling to compete in a new world full of other vendors and viable open-source alternatives? The first project that comes to mind is Pusher.

For years, Pusher has been the default answer to “how do I add realtime to my app?” Easy to start, SDKs everywhere, it Just Works™. While everyone was afraid of self-hosting WebSockets, Pusher offered an easy way out. Don’t underestimate the power of irrational fear: even though open-source reverse-engineered alternatives have been known for almost as long as Pusher exists, they were barely used outside of local setups and experimental projects (I remember suggesting switching to Poxa, an Elixir-driven OSS alternative, back in 2016—that was a hard sale, we failed).

Pusher’s protocol became a de facto standard. Laravel built its entire Broadcasting layer around it. Countless apps speak Pusher protocol without thinking twice. Well, until the invoice arrives. Or you need delivery guarantees. Or you want your data on your infrastructure.

The demand for real-time features in 2026 is not the same as in 2016 (no, I don’t want my 2016 back; I live today). The supply has changed too: more PaaS options arrived, popular frameworks got built-in real-time engines (Action Cable in Rails, Reverb in Laravel), new protocols emerged to satisfy new needs (yes, I’m talking about Durable Streams, again). And Pusher stays basically the same, not from the features they offer but from the way developers use it.

We’ve seen many applications using Pusher, many developers unsatisfied with its features and limitations, and managers unsatisfied with the bills. That triggered our decision to support the Pusher interface in AnyCable. The goal is not to lure the clients but to provide a smooth migration path towards better realtime UX.

Today, switching your application from Pusher (PaaS) to AnyCable is just a matter of configuration. This is the first phase. After finishing the infrastructure migration, you can gradually migrate to other protocols better suited to your needs: whether it’s server-sent events, or durable streams, or reliable WebSockets backed by the AnyCable protocol—the choice is yours and yours only.

The future of realtime web must be reliable and affordable. Be a part of it and don’t let the next “An update on …” post take you by surprise.

In this issue, we’ll cover all interesting stuff happened in the last few months.

News

37signals released Fizzy

Fizzy is a (kinda) open source Kanban-style task manager. All its real-time features are powered by Turbo Streams (and Page Refreshes). You can use a SaaS version or host it yourself (and, you can modify it: for example, migrate to AnyCable 😁).

Announcing Durable Streams

Team ElectricSQL announced a new HTTP standard proposal—Durable Streams.

The core idea: streams are a first-class primitive that get their own URL. Each stream is an addressable, append-only log that clients can read from any position.

We at AnyCable have already started adopting the new spec, so stay tuned for the updates early next year!

Posts

AnyCable, Rails, and the pitfalls of LLM-streaming

This post demonstrates UI/UX hallucinations that could happen when streaming LLM responses over not-so-reliable channels (like Action Cable).

Notes from building a “who is doing what right now on our website?” presence feature with Action Cable

Ben shares the story of building a presence feature in a an Action Cable-backed Rails application.

Releases

anycable · 1.6.7-1.6.8

The recent releases of AnyCable bring more stability, performance, and observability improvements, as well as security fixes. Please, upgrade! ‼️

anycable-rails · 1.6.1

We’ve upgraded our interactive installer, so it fits new Rails defaults better, and helps you set up AnyCable in a reliable mode right away.

turbo_cable

A custom (and minimal) Ruby WebSocket server for Turbo Streams.

Subscribe now

Highlights

AnyCable Thruster Pro

As Thruster becomes more popular in the Rails world, so does its AnyCable-d version. It’s not surprising: running AnyCable for Rails with Thruster is as simple as changing a line in the Gemfile!

Now, you can also switch to AnyCable Pro with a one more configuration change!

Posts

AnyCable for Laravel: reliable WebSocket infrastructure

We continue our work on AnyCable integration for Laravel. This post introduces AnyCable’s Pusher (and, thus, Reverb) protocol compatibility and a dedicated Echo adapter. It also includes load testing results and comparisons (no spoilers, go to the post to see the numbers).

Videos

Phoenix LiveView: Mastering Reconnects for a Seamless User Experience

This talk from ElixirConf EU 2025 explores the problem of restoring a connection state (more precisely, a LiveView component’s state) on reconnect. There are a few techniques presented, most are specific to LiveView, except the very last one (which I liked the most): Prefer “I haven’t figured out” mindset over “It’s a technology limitation”.

Klipshow From Scratch Ep. 4: Real-Time WebSocket Alerts + OBS Integration + AnyCable Architecture

In this YouTube series, Johny builds a production Rails/React application (Klipshow, a Twitch monetization platform) in real time and thoroughly explains everything he does. This show is a good collection of how-to-s for a variety of modern Ruby on Rails tools (Turbo, AnyCable, SolidQueue, etc.). Subscribe!

Podcasts

OnRails: Inside Doximity’s 15-Year Rails Monolith

Throughout the episode, they share pragmatic insights into debugging at scale, managing one-off data migrations, and determining when a service should live inside or outside the monolith. They also reflect on their use of tools like Packwerk, AnyCable, and Departure, and how a culture of trust, documentation, and lightweight planning helps Doximity move fast without breaking things.

Releases

anycable · 1.6.6

We’ve released a few patch version of AnyCable during the summer with some tiny but helpful features. Check out the change log!

once-campfire

Campfire, a simple group chat app built at Basecamp, that was previously commercially available via the Once model is now open sourced! Feel free to play with it, modify and share your mods with the world! (That’s what we’re going to do soon 😉)

Frame of curiosity: y-j-s

In just about a month, we’re holding the very first SF Ruby Conference. Apart from various AI-related talks, there is one hidden gem (from this newsletter point of view)—a talk by JP Camara on Real-time collaboration with Rails, AnyCable and Yjs. I don’t know (yet) what it’s gonna be about, but I have some thoughts on the subject I’d like to share.

SF Ruby Conference is happening on November 19-20, 2025. Grab a ticket here: https://luma.com/sfrubyconf2025?coupon=ANYCABLE ($50 off!).

So, what is Y.js, and why should you care? Y.js is a CRDT (Conflict-free Replicated Data Type) library that solves the distributed state synchronization problem. In practical terms: it lets you build collaborative features where multiple users can edit the same data simultaneously, and all changes merge automatically without conflicts. Think Google Docs, but for any kind of shared state—collaborative whiteboards, forms, design tools, or even project management boards. If your users need to work together on something in real-time, Y.js handles the hard math so you don’t have to.

The Rails community has flirted with Y.js before. If you have been following us for a while, you should remember the yrb-actioncable project. However, we haven’t seen a lot of people building with it (probably, because it’s incompatible with AnyCable, and we mostly work with it).

But here’s the exciting part: recently, a Go port of Y.js has been released. Wait, Go? Yes! This changes everything. We can move all the CRDT complexity to AnyCable and expose a simple, clean API to bring collaborative features to any Rails (or PHP, or...) application. No more worrying about Ruby’s performance characteristics for handling high-frequency CRDT updates. No more binary protocol gymnastics in your application code. Just a straightforward API that lets you add “Google Docs-like” collaboration to your app!

That’s something we’ve been keeping in mind for a long time, and it seems it’s getting closer to reality. Sounds exciting to you? Let’s chat in San Francisco in November!

Subscribe now

Highlights

AnyCable meets Kamal

You asked, we listened. Our documentation now includes a detailed guide on deploying AnyCable with Kamal. It covers various possible setups depending on the number of machines and required configuration.

Posts

AnyCable vs. Action Cable: A Benchmark War

The post by Alex Aslam shares a lot of insights and numbers from battle-testing Action Cable vs. AnyCable. I especially like the “Failure Recovery” test—something people rarely pay attention to:

Releases

websocket-bench · 0.4.0

We’ve updated our benchmarking tool to support Pusher-compatible servers (such as Soketi or Laravel Reverb). Stay tuned for some Laravel AnyCable benchmarks!

Frame of the future: SF Ruby

We run the new San Francisco Ruby Conference on November 19-20, and because—we know!—you are building amazing things, we’d love you to send us a talk proposal, or demo your Ruby startup at the conference. CFP for talks closes this Sunday, July 13, EOD. Join this new and exciting Ruby conference!

Subscribe now

We’re thrilled to introduce AnyCable for Laravel—a production-proven real-time server now available in preview. Think of it as a friendly handshake from the Rails ecosystem, returning the love after Inertia.js made its way from Laravel to Rails. Let’s keep building bridges!

AnyCable brings 7+ years of Rails-scale reliability to Laravel, designed to complement the tools you already love and act as a natural add-on for Laravel apps, not a foreign component. In other words, it’s a new Laravel Broadcasting backend in addition to Reverb, Pusher, and others. Your backend real-time logic (events, etc.) stays the same. Your client-side logic (Echo) can remain the same.

Our first Laravel-aware release includes the broadcast adapter library and limited Pusher protocol support (for now)—just enough to get started with AnyCable.

We plan to bring better Reverb compatibility and port AnyCable-specific features in future releases. But first, we’d love to hear from the community!

Ask questions, raise concerns, request features—your feedback will help shape what comes next.

I know that the first question is going to be “why”. Why use AnyCable when we have Reverb, Pusher, Soketi, and so on? So, let me try to answer it right away.

1. Reliability and Developer Experience for Real-Time Features

AnyCable is built to make WebSockets truly reliable—going far beyond basic connectivity. With features like reliable streams and resumable sessions, AnyCable ensures your users never miss a message, even if their connection drops for a moment, whether they’re riding the subway or just dealing with everyday WiFi hiccups. As a result, your users get a smooth and dependable real-time experience.

Other key reliability features include:

• At-least-once delivery: Delivery of messages is guaranteed, and when the client-side handles potential duplicates, we achieve exactly-once.

• Automatic state restoration: Upon reconnection, clients automatically catch up on missed messages and resume their session without re-authentication or re-subscribing to channels.

• Fallback transports: Beyond WebSockets, AnyCable supports Server-Sent Events and long-polling, so your real-time features work everywhere.

2. Scalability and Performance

AnyCable is written in Go, giving your Laravel app a high-performance WebSocket server that takes the load off your core PHP processes. This unlocks greater scalability for real-time workloads, letting your main app focus on business logic while AnyCable handles thousands of concurrent connections with low latency.

• Effortless horizontal scaling: Seamlessly scale with Redis or NATS or use embedded NATS for clustering—no extra infrastructure headaches.

• Optimized resource usage: Go’s efficiency means less RAM and CPU per connection, making it cost-effective as your app grows.

• Observability and tooling: The AnyCable ecosystem includes everything from Grafana dashboards for real-time monitoring to a k6 plugin for load testing, so you can confidently operate and scale your real-time features.

Importantly, we haven't benchmarked AnyCable against Reverb or Soketi yet. Stay tuned!

3. Open Source and Always Will Be

AnyCable is open source and here to stay—feel free to screenshot that for posterity. The core is free, and always will be. For teams with massive scale, there’s a commercial version with extra features, but you only pay if you need it. There’s also a free managed offering (plus.anycable.io) that already supports Laravel!

Built by Evil Martians, a team focused on developer tools, AnyCable is designed to fit naturally into your Laravel workflow. For example, you can launch the server locally with a single Artisan command:

php artisan anycable:server

No manual installs or downloads—just Laravel simplicity.

In short: AnyCable brings production-grade reliability, performance, and developer experience to Laravel’s real-time features, while being open and flexible for teams of any size.

Highlights

AnyCable meets Laravel!

AnyCable opens up a new frontier: we’ve started working on bringing better real-time capabilities to Laravel users. Laravel is a cousin-framework to Ruby on Rails; it’s based on the same ideas and ideals. Even though the frameworks now evolve independently, we believe there is still room for sharing (or cross-pollination). AnyCable worked out great for Rails—why can’t it be useful to Rails’ distant relative?

Today, we’re taking the first step towards Laravel Cable: meet the AnyCable broadcasting adapter for Laravel. We’ve also added limited Pusher protocol support to the AnyCable server—just enough to get started with AnyCable as a Laravel Reverb drop-in replacement..

Laravel-ready AnyCable is already available on AnyCable+ managed service for early access. Give it a try!

AnyCable Laravel is still in its early days, and we’d be happy hear your feedback and suggestions on how to move forward with it.

News

SF Ruby Conference 🌁

Brought to you by the same people behind AnyCable, SF Ruby Conference is a premier Ruby event focused on startups (at all stages, from idea to IPO), open-source and AI tools, and other Silicon Valley-relevant topics. Come join us in San Francisco this November!

Posts

Building a real-time WebSocket leaderboard with Centrifugo and Redis

Our friends from Centrifugo recently released a new feature—delta compression in channels. The blog post demonstrates this by building a real-time leaderboard.

Releases

anycable · 1.6.2

This release brings the initial Pusher protocol support we’ve already mentioned, as well as some minor features that we’ll cover in future issues. Stay tuned!

anycable-laravel · 0.1.0

Meet our very first PHP package! We’ve started with a Laravel-specific library, but designed it so the core AnyCable logic (broadcasting, stream signing) can be easily extracted in the future (currently, it lives in a single AnyCable\Laravel\Client class). Work with PHP but not Laravel and want to give AnyCable a try? Let us know and we’ll extract the core into our second PHP package 😁.

Frame of curiosity: vibe-deeping

In the previous issue, we mentioned a new AI service—DeepWiki. It takes a GitHub repo and turns it into a documentation website. The resulting documentation is heavily code-centered and, thus, looks more like a service or repair manual, not a user guide. However, this property is beneficial to those trying to figure out how things work, rather than just how to use them–like me 🙂.

In combination with the built-in chat-to-ask capabilities, DeepWiki becomes a great learning tool for curious engineers.

Here are a few examples of questions I’ve asked recently (so you can guess what I’m working on in my not-so-spare time 🤫):

• How does JS agent…

• How to add new files to the FileTree…

• Which Pusher protocol features…

• How cache channels work…

Got an idea? Give it a try and don’t hesitate to share your insights!

Subscribe now

Highlights

AnyCable v1.6 is out!

The long-awaited AnyCable release with presence tracking support is available everywhere: you can quickly spin up a cable at plus.anycable.io, download an OSS version or go Pro w/ presence tracking for clusters support.

Now, when this big release is out, you may ask—what’s next? Our primary focus for the rest of the year is, first, to incrementally enhance presence-related features (WebHooks, HTTP API, etc.) and, secondly, to bring more ready-made components for building real-time applications (e.g., UI kit and stuff). Speaking of components…

Posts

Simple Declarative Presence for Hotwire apps with AnyCable

Learn more about our Hotwire Presence component that can help you add presence tracking features by just using HTML!

Improving WebSocket performance at Clio

The Clio team shared the story of improving the performance of their real-time features (powered by AnyCable):

What could be done to improve WebSocket performance? We identified three solutions:

• Decrease the number of WebSocket messages sent from the frontend to the backend

• Scale AnyCable’s servers

• Make Clio’s code process WebSocket messages faster.

News

Terminalwire is open source

Terminalwire allows you to easily create a CLI interface for your web application (a “thin client”—a term from the past) fully defined on the server (commands, options, etc.). It’s like Hotwire but for CLIs. Under the hood, the command-line tool uses a WebSocket connection and a custom protocol to execute commands. The source code can be used as an example of using async-websocket to create WebSocket clients in Ruby.

Releases 🤖

deepwiki.com/anycable/anycable

Say hello to our new documentation website! This is joke, of course; our new documentation website will be much better. Still, such AI-generated source-to-documentation resources could be useful in learning more about the internals of the project you want to hack with. Don’t hesitate to give it a try!

Frame of history: Comet

Yesterday, we (Team AnyCable) visited the Computer History Museum in Mountain View, CA. It was a great time-traveling experience and a demonstration of how quickly the industry evolved over the last (half-)century (and how small the first iPhone was compared to modern models, even my beloved mini). And it also felt a bit strange; another visitor nailed it, saying: “How strange it is to see the things you actively used in the past now being a part of a history museum collection?”

We don’t have a museum of real-time web yet, even a digital one, but there are definitely good candidates to add to its collection. And the first thing that came to my mind with regards this idea is Comet, an umbrella term for push-style/streaming HTTP communication used in the late 90s and early 00s. It was usually contrasted with a request-response-ish Ajax, a super-hot technology back in the day that is still very much alive today (though since the decline of $.ajax and the rise of fetch, we barely use this legacy term).

As an exhibit to represent Comet in our mythical Real-Time Web Museum, I would pick the original blog post by Alex Russel that introduced the term. I leave you the opportunity to read the blog from the past in its entirety yourself. Here I just want to pull out some quotes and add a few remarks.

…Lacking a better term, I've taken to calling this style of event-driven, server-push data streaming "Comet". It doesn't stand for anything, and I'm not sure that it should.

I don’t know if it’s a coincidence or not, but in the context of Ajax, Comet had a clear (clean?) meaning—both names have been used by popular cleansers since mid-20th century:

Common terminology acts not only as a shortcut in discussions between technical folks, but also as a bridge for those who may not be able to give a technical rundown of exactly how it works… We have a hard problem for which solutions are available (and have been for some time) but no way to communicate about them. Terminology is again the missing link.

We all know that naming things is hard; but this post goes further and discusses the problem of having no good name for a common set of problems or solutions.

The term “Comet” hasn’t become The Term. Today, we use the word “real-time” to describe asynchronous/bi-directional/low-latency communication, and most of the times we use a particular transport name along with it (WebSockets, SSE, WebRTC). We still can’t separate the concept (realtime-ness) from technology.

P.S. Can you count the number of times the term “real-time” used in the Comet blog post?

Subscribe now

Videos

Presence ain’t perfect

This is the video from latest SF Ruby Meetup in which we presented the brand new AnyCable Presence primitive along with its Hotwire component—the <turbo-cable-presence-source> element. We’re close to the final release of the feature, documentation and more!

Posts

Adversarial Web Services

This post gives an alternative meaning to the "AWS" acronym, going into details regarding the pitfalls of using AWS. The part about API Gateway WebSockets limitations and the cost calculations is of most interest to us:

If you have 50k clients you'll pay AWS 200€ every month just to keep them connected to a WebSocket 24/7. For comparison, a 60€ EC2 instance can handle more clients than that with no limitations.

News

Hatchbox upgraded AnyCable support

Now running AnyCable on Hatchbox is as simple as adding a line of configuration!

Releases

@anycable/core · 1.1.0

This release brings many improvements around using authentication tokens. For example, you can now specify the token as a WebSocket sub-protocol (to not expose it in query params and, potentially, server-side logs). Note: this feature requires the latest RC of AnyCable 1.6.

@anycable/turbo-stream · 0.8.0

This release brings experimental <turbo-cable-presence-source> element that powers AnyCable Presence features to Hotwire. It’s still early days of this integration, so we’d love to hear your feedback! You can see it in action in this demo application.

Frame of curiosity: don’t slow your roll

Have you ever heard of a slow client problem? This happens when a socket cannot read data as fast as it's written into it. The causes vary from poor network to malicious actors. Yes, slow clients could be used to perform DDoS attacks. It's hard to distinguish a good client with low bandwidth from a bad client configured to read slowly intentionally.

Okay, how exactly can slow clients harm your system? This article in La Nueva Escuela blog provides a good illustration (and explanation) on how slow clients affect systems of different types—with blocking and non-blocking write operations.

Basically, there are two possible outcomes (if you don’t guard yourself from the problem): either your whole application periodically stalls for a noticeable amount of time, or you memory usage grows significantly (example issue). The former happens when writes are blocking and the latter is a result of buffering data before performing the actual write into a socket.

For example, in Node.js I/O writes are non-blocking and in Go they’re blocking (by default). In Ruby, I/O objects have both #write and #write_nonblock methods (though the latter may raise an exception if the underlying buffer is full).

How does this affect real-time applications and WebSockets in particular? And how can we prevent the potential consequences of serving slow clients?

Recently, one of AnyCable users, Caleb Thorsteinson, shared his investigation regarding increased broadcast latency when there are slow clients and a high broadcast rate. AnyCable server is written in Go, so writing messages to clients is a blocking operation; however, there is a buffer and a write timeout in place: that's how we protect the pub/sub component of the server from becoming unresponsive when trying to serve slow connections. Still, under some circumstances, that wasn't enough.

Caleb shared a minimal reproduction setup involving a few scripts to create subscribers, perform broadcasts at a given rate and a Toxiproxy configuration. Toxiproxy is an indispensable assistant in all kind of non-ideal network test scenarios.

With the help of the load test (more precisely, its upgraded version), we were able to measure the effect of slow clients on such WebSocket servers as Action Cable (w/ Puma), AnyCable, and Centrifugo.

Action Cable uses I/O polling to detect when the socket is writeable, and there is a buffer to store pending messages. There is no buffer size limit nor timeouts. Hence, when there is a slow client, the Action Cable server memory usage grows as we continue broadcasting messages. In our tests, the memory grew from 380 MiB to 450 MiB with just a single slow client in 10 minutes (and 20 messages per second sent). Without slow clients, the increase was just ~10 MiB.

In the case of AnyCable, we were able to reproduce the original issue—a server's pub/sub loop is blocked when writing to a slow client until the timeout triggers and we forcefully close the connection. In theory, that should have been enough; in practice, our default timeout value was too high—10s. So, some broadcasts could get stuck for 10 seconds—not good. We also used a Go channel as an application-level buffer for outgoing messages; this is a typical approach for Go applications, but it doesn't take into account payload sizes. We fixed this by switching to a queue as a buffer and adding pending data size tracking: whenever a client exceeds a limit, we mark it as slow and disconnect. Thus, writes are non-blocking now, and the potential memory increase per connection is capped. The queue idea was borrowed from Centrifugo, which we tested and confirmed that it handles slow clients well.

The change will ship in AnyCable v1.6 (and is already available in the latest release candidate).

Subscribe now

If you happen to be around San Francisco next week, come say “hi!” to us at the SF Ruby Meetup where Team AnyCable will be hanging out (and giving talks). Or you can join the live stream 🎥!

Posts

Back to Basics: Why We Chose Long Polling Over WebSockets

This story of favoring long-polling over other transports in 2025 is an interesting read. Just check out the analogy:

Short polling is like a train that departs strictly according to a timetable—it leaves the station at fixed intervals regardless of whether there are passengers or not.

WebSockets, on the other hand, are like having a dedicated train line always ready to transport passengers.

Long polling? It's like a train that waits at the station until at least one passenger boards before departing.

(Although I would say that WebSockets are more like taxis; there is no overhead for pulling a whole train just for the sake of a single passenger.)

Monitoring Action Cable

Learn how to make Rails Action Cable instrumentation-friendly and expose metrics to Prometheus (using the Yabeda framework).

Guide to Twilio + OpenAI Realtime on Rails (Without AnyCable)

One more blog post about stitching Twilio Media Streams and OpenAI Realtime together; this time, in pure Ruby (as you might guess from the title). We shared our AnyCable-ed version a couple of issues ago.

Releases

actioncable-next · 0.2.0

A new release of the future Action Cable brings various performance improvements. The most significant one is fastlane broadcasts support (or less JSON encoding/decoding). See more in this PR. And here are some benchmarks:

anycable-rails · 1.6.0.rc.1

This release brings AnyCable presence (which we’ve announced the last time) to Action Cable channels:

centrifugo · 6.0

A new chapter in the life of our friends from Centrifugo.

Frame of curiosity: ping pong 🏓

Persistent network connections (like WebSockets) require a mechanism to inform each communication end (say, client and server) whenever the other one unexpectedly goes out of sight, to distinguish silence from disrupted connectivity. This discovery can be implemented at a different level (or layer). For example, TCP protocol supports sending tiny keep-alive packets to detect network failures (as we explain in our documentation).

Usually, higher-level protocols (Application Layer) implement their own heartbeats. The primary reasons are better control over heartbeat logic (e.g., intervals, etc.) and proxy/firewall handling (as some intermediate nodes might skip keep-alive packets).

Both WebSockets and HTTP/2 come with their own heartbeats: PING/PONG messages. Yet almost all realtime protocols/frameworks implement their own keepalive logic! We can see “ping”-”pong” (or “ok”-”ko”) messages passing through every WebSocket connection. Why so? Primarily because pings and pongs are hidden from client-side (browser) code: you can’t initiate them, you can’t listen to the corresponding events, you don’t even know if the server uses them or not (more info here).

So, we add ping-pong-like features to our realtime protocols.

Let’s consider Action Cable, for example. The server sends a “ping” message to every connected clients every 3 seconds. The client uses this pings to detect if the server is still alive and operational (i.e., it not only checks connectivity but verifies that the server can do its job). Here’s an important difference from lower-level heartbeats: the network could be up, while the server (in this case, a Ruby application) experiences performance issues—it’s better for clients to know about that and try to re-connect to a different node*.

In many cases, “ping” messages (when accompanied by “pong”-s) are used to measure the latency between the peers (see the Action Cable metrics article linked above). That’s another reason for having them.

Thus, protocol-level heartbeats are justified. However, at scale, the number of transmitted messages could be enormous. For example, with 10k Action Cable clients, the server sends ~3k messages per second.**

From the client-perspective, receiving and sending pings is also not free, especially, for mobile devices: you can easily drain power by constantly asking a mobile app to process pings. (That’s why we made it possible to configure ping interval on per-client basis in AnyCable.)

Know your pings!

* Ping in Action Cable are only goes in one direction, from server to clients; unfortunately, that doesn’t prevent all the possible networking problems. See this PR for discussion.

** The calculations are borrowed from this issue.

Subscribe now

Highlights

AnyCable Presence is coming!

A long-awaited feature is coming to AnyCable—presence tracking. We’ve just released the first release candidate for the upcoming 1.6 version with presence tracking capabilities. You can check this feature out via our Stackblitz demo or by creating a new server on AnyCable+ (yes, the feature is already available there).

As you can see from the docs, presence tracking is quite a complex feature consisting of multiple components. We’re going to incrementally release them over the next months. Stay tuned!

News

Supabase Edge WebSockets

Supabase announced WebSockets support for Edge functions. Although it opens some new possibilities (the primary use case OpenAI Realtime which we discussed in the previous issue), the duration limits must be taken into account (making a client re-connect and re-initialize every few minutes may not work for your application). (Have Supabase invented WebSockets Long Polling 🤔?)

Talks

Streaming over the web with modern Ruby

Shannon Skipper provided a great overview of realtime transports in his recent RubyConf talk: WebSockets (not dead at all), WebTransport (not-so-close future), SSE, HTTP chunking.

Releases

LiveView · 1.0

Congratulations to the Phoenix team and Chris McCord for reaching this milestone!

anycable-go-client

Want to connect to AnyCable or Action Cable server from another backend application? Here is an open-source Go library for that!

async-cable

This library aims to provide better Action Cable experience for Async Ruby / Falcon users. It relies on the Action Cable Next project which we mentioned a few times this year.

twilio-ai-js-demo

Recently, Irina presented the Next.js version of our Rails Twilio OpenAI Realtime demo. It demonstrates how AnyCable-based realtime server can stay language and framework-agnostic and work with any backend!

Frame of remembrance: Noah Gibbs

The end of the year brought us sad news: a prominent member of Ruby and Rails communities, the author of an amazing “Rebuilding Rails” book and many more, Noah Gibbs has passed away (/r/ruby).

Let me share you one story (related to our newsletter’s primary topic).

I first met Noah at SouthEastRuby conference in 2018 where we were both speaking. We’ve likely seen each other before at larger conferences but had no real opportunity to chat; the regional conferences are much better for finding new friends in the community.

Over three days, we had a few thoughtful conversations, technical and not, but one topic stayed with us for quite some time after the event—Action Cable. I still smile when I recall how right during the conference Noah sent me a link to a secret gist titled action_cable_weird_shit.txt. It contained a dozen questions and notes on the library sometimes surprising or unclear behavior, and we walked through it trying to fill the gaps.

As a result, Noah wrote a great article called “Does ActionCable Smell Like Rails?“. This article is a reflection of a seasoned developer, the framework expert, on the evolution of Rails. Something bothered Noah (“A Rails API is often carefully polished… ActionCable isn't there yet”), and he tried to find the answer for himself and share his findings with the community—I believe the latter was more important to him than the former. That was Noah. That’s what we all will miss ❤️.

Subscribe now

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

anycable-go · 1.5.4

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.

Subscribe now

News

Rails 8 (beta) is out!

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 Realtime API

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

actioncable-next

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 · 1.3.0

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 👻

Subscribe now

Posts

Connection avalanche safety tips and prepping for real-time applications

Connection avalanche is a kind of thundering herd situation specific to real-time applications. This post gives an overview of possible prevention and mitigation measures. Even if you don’t expect high loads any time soon, it’s better to be aware of potential issues that may occur as you grow.

News

AnyCable collaboration UI kit

We’ve been dreaming of providing some kind of real-time kit for AnyCable users for a while, and finally, the work has started: we’re happy to (pre-)announce our ready-made real-time components. The UI/UX part is mostly solved, and we’re ready to start working on the actual implementation. What do you think? Share your thoughts/suggestions on this initiative–respond to this email, or leave a comment on substack.

Events

Developer Tooling For The Modern Hotwire & Rails Era

Marco Roth travels across the world and shares his vision of the future of Hotwired Rails. Check the slides (videos are coming later) and see how much effort Marco puts into improving developer experience (DX) for engineers working on Hotwire applications—this is what the future development looks like, with DX as the top priority for engineers.

Releases

anycable-pubsub-nextjs

We made the source code of our Stackblitz-hosted AnyCable Next.js example available on GitHub. Feel free to hack around with it on your machine!

@anycable/core · 0.9.1

This tiny release brings one new useful feature: the ability to react to history-related events (e.g., `history_not_found`), so you can implement application-specific fallbacks. Check out this PR to learn more.

Frame of curiosity: per-room vs per-user subscriptions

Recently, I had a discussion with one of the AnyCable Pro clients on their real-time application design. They build a chat-like application with users and conversations, and they started to question the design of the underlying real-time functionality (receiving conversation updates): “Are we modeling the real-time communication correctly?”, “Will it scale?”. I believe engineers must question themselves and re-visit their prior decisions regularly—that’s one of the keys to staying afloat. But we’re not here to talk software engineering philosophy stuff; let’s go back to the technical problem under consideration.

So, let’s assume we have users and rooms in our chatty application. Rooms can be public with many members or direct messaging rooms with just two communication ends. Here is, for example, our AnyCasts demo:

A typical approach in modeling real-time communication in chat rooms is to have a RoomChannel (we’re going to use Rails Action Cable as an example):

class RoomChannel < ApplicationCable::Channel

def subscribed

room = current_user.rooms.find_by(params[:room_id])

reject unless room

stream_from room

end

end

And then, when we want to deliver a new message, we broadcast it to the room:

class Room < ApplicationRecord

after_create_commit do

RoomChannel.broadcast_to room, serialize(self)

end

end

This is an example of per-room pub/sub model: for each chat room, we have a dedicated stream, and users subscribe to the relevant room streams to receive live updates.

This is a very efficient model in terms of broadcasting since it fully leverages pub/sub capabilities: we don’t care about actual subscribers when we deliver updates, all we know is the stream name. However, from the client-to-server communication point of view, it has some drawbacks.

Imagine we have a Chats screen where we list all the user’s conversations. In order to show new messages on the list, we should subscribe to all conversation streams! And there could be dozens and even hundreds of them. Surely, the WebSocket connection is still the one, but performing “subscribe” requests is not free (especially, in the example above when we reach out to the database to verify access).

Even if we don’t show updates on the Chats screen, browsing conversations may feel laggy, because we need to subscribe every time we open a chat screen (and unsubscribe afterward).

So, after facing such challenges, many decide to look at the kinda opposite strategy—per-user streams.

When using per-user streams, you only have a single stream per user but perform as many broadcasts as the room members number for every message created:

class UserChannel < ApplicationCable::Channel

def subscribed = stream_from current_user

end

class Room < ApplicationRecord

after_create_commit do

room.members.each do

UserChannel.broadcast_to(_1, serialize(self))

end

end

end

This approach drastically simplifies the client side of the communication: just a single data stream to consume updates from. You subscribe once, and it’s always on, you just need to route messages to the corresponding stores.

Well, the server could be not so happy with this change: now it has to perform O(N) broadcasts every time a message is created/updated, where N is the number of room members. In other words, we ditched the pub/sub idea completely. (With AnyCable’s batch broadcasts, we can reduce the overhead, but still…)

As in many software problems, a combination of multiple techniques works better than each one independently. Instead of choosing either per-room or per-user approach, think of using both. For example, for DM conversations, using per-user approach makes sense: the number of DM dialogues can be huge but the number of members in each is very limited (so, the broadcasting overhead is negligible). For crowded public channels, it’s better to stick with pub/sub, i.e., per-room subscriptions.

Thank you for reading. See you next time!

Subscribe now

News

AnyCable is on awesome-selfhosted!

Videos

Mocking WebSockets with MSW

Mock Service Worker is a popular tool to fake APIs for JavaScript applications. Since the next version (available in beta), it supports mocking WebSockets, too! So, you can mock your WebSocket server in integration tests instead of running it (which is especially problematic with PaaS-es).

Releases

caddy-anycable 🎉

Say hello to the official AnyCable module for Caddy! Now you can embed AnyCable into your application server and reduce the number of infrastructure components. (Read more about Caddy in our previous issue).

anycable-rails · 1.5.2

AnyCable Rails now automatically detects Devise and activates the Warden middleware for RPC requests (so your authentication must work without any additional configuration).

anycable · 1.5.1

This release introduces Rack 3.1 compatibility.

Frame of curiosity: be your self-hosted

Have you ever wondered how many third-party infrastructure* services your application depends on? Okay, don’t start counting now (it could take time), bear with me for a minute. (*By “infrastructure“ we mean those not responsible for your application business logic.)

In the old days of bare metal servers and HTML 4.0 web applications, we hardly had any third parties involved in the process of deploying and maintaining our code. Cannot believe this? Let’s compare my very first production setup (circa 2010) with what we typically have nowadays (in the old vs. new format):

• SVN/FTP vs. Git (hence, we didn't even use GitHub)

• make test && cap deploy vs. CI/CD

• sendmail vs. Mandrill/SES/Resend/etc 

• tail error.log | grep vs. Honeybadger/Sentry

• Monit / cron + curl vs. monitoring/uptime services

• Erlang/OPT vs. Pusher/Ably (yeah, we were early WebSockets adopters)

No, I’m not going to say that the grass was greener—there was no grass, that was a scorched desert. And it turned out to be very fertile soil—today we rely on many services while operating our applications. Sometimes they go down (and we—for another cup of coffee/tea); the more services you have, the more likely you’re affected by their health — a micro-(third-party)-services problem. (And I’m not even talking about $.)

Thus, although SaaS solutions proved to be helpful, even essential for web applications engineering and operations, it never hurts to consider self-hosted alternatives. Today, self-hosting is very different from 10-15 years ago; it’s not about dealing with tons of scripts and configuration tuning or writing custom code; usually, it’s just about running a single command to spin up a server and configuring it via a web UI—not more complicated than providing your billing information to a third party. The benefits are still the same: cost, privacy, and customizability.

For example, we at AnyCable self-host uptime monitoring via Uptime Kuma and are considering switching to a self-hosted telemetry solution. What about you? (Check out awesome-selfhosted for some inspiration.)

Posts

Experimenting with real-time data compression by simulating a football match events

Our friends from Centrifugo recently released the delta compression feature for WebSocket clients, which they explore in this post using a football (or soccer) game live translation as an example use case. Great post and a very good example given that Euro 2024 is just around the corner (Forza Italia 🇮🇹!)

(If you want to dig deeper into the delta compression topic, check out our Issue #15, where we talked about the diffing problem for real-time streams in the context of LiveView and Turbo Streams).

LiveVoice shares how they use AnyCable

Read the story by Sebastian Poell, AnyCable user and LiveVoice co-founder, on how they use AnyCable to power real-time interpretation for guided tours. What I like most about this case study is that it’s full of technical details and real-time tips (i.e., not a marketing BS).

Releases

anycable/thruster · 0.1.x

Thruster and AnyCable walk into a bar… Yes, this is a mix of two to make you run one process less! Check out this demo PR (also including a freshly released capybara-thruster to speed-up your system tests).

@anycable/turbo-stream · 0.7.0

This release introduces a new configuration option—delayedUnsubscribe. This setting aims to solve a common problem (or peculiarity): avoid instant subscribe-unsubscribe commands in case the new page HTML contains the same <turbo-stream-source> elements (so our server does not process useless commands and our clients do not miss messages in-between).

@anycable/core · 0.9.0

This release fixes a bunch of TypeScript inconsistencies.

anycable-go · 1.5.1-1.5.2

These tiny releases makes Server-Sent Events via AnyCable as powerful as WebSockets by porting all the missing features (signed streams, history offset, etc.). We also added raw mode for SSE clients to receive only data messages ignoring all protocol events.

Frame of curiosity: to thrust or not to thrust?

Thruster is going to be a part of Rails 8 distribution. Well, not a anymore (and I’m glad we didn’t publish this issue a month ago 😁). Nevertheless, it is still worth discussing this potential change in the way we serve our Rails applications locally and in production.

Thruster is a standalone proxy server which aims to stand in front of your bin/rails s and do some routine work: serve static assets, terminate SSL, etc. The concept of having a non-Ruby web server is not new to Rails (remember Passenger?), so why do we cycle back to it again? Because, it’s 2024, and not using HTTP/2+ and manually generating SSL certificates (when deploying on bare metal) is too old school even for Rails developers. DX (Developer eXperience) is what engineers care about today (if you don’t—please, start right now). And Thruster aimed to provide a decent one (“Heroku-like”) for one-person Rails installations. “Aimed”, because it seems that Kamal 2 Proxy is going to replace it for production deployments. We’ll see this September.

In any case, Rails 8 will have an official reverse proxy, whether you need or not (--skip-kamal). Of course, there are alternatives starting from good old Nginx (or its Unit version) and continuing with Caddy, a modern and extensible application server. Let’s pay a bit more attention to the latter one.

As I said, Caddy is modern: supports HTTP/2 (and HTTP/3, if you wondered) and it manages SSL certificates with a matter of a configuration change (even for localhost). What’s more important, it has a pluggable architecture, and you can extend it via modules. There are some built-in modules (mostly typical reverse proxy features, such as redirect rules, etc.) and plenty of custom extensions (GeoIP decoding, caching, and many more). And of course, you can write your own!

Of course, the cherry on the top is the fact that Caddy has been running tons of applications for years. It’s a robust piece of software, so why can’t Rails developers benefit from using it like some PHP devs do via FrankenPHP? Why can’t we extrapolate the success of using Caddy for Rails applications deployment from Hatchbox to everywhere else, including our local environments?

These questions have been bothering me since the very introduction of Thruster. Surely, greenfield Rails apps would benefit from Thruster/Kamal Proxy right away; it’s simple and it works (though it will take quite a bit of time to stabilize and mature); we can even extend it like we did with AnyCable Thruster; but we’ll inevitably hit its limits; and I’m afraid sooner than later.

That’s why we (some mysterious “we” for now) started an R&D project on building a smart reverse proxy for Rails applications on top of Caddy, covering use cases not only observed once but by many diverse applications and teams. And we want to make useful, Rails-friendly extensions for HTTP available out of the box: AnyCable, imgproxy, Wafris, etc.

If you like this idea, please share your suggestions on what might be nice to have in such a Rails-oriented application server.

LiveVoice is completely running on AnyCable - and it really rocks ;) I have to say, seeing the CPUs on an AWS c6g.2xlarge instance at only 6% utilization for 10K listeners is pretty crazy (in a very positive way) ^^ Aside from performance, using AnyCable fixed every issue we ever had with ActionCable (broken connection detection, race conditions, ...).

We got excited and asked Sebastian for a few more details about the use case. But could we have imagined that Sebastian would write not just some sentences, but a full story of LiveVoice and the role of AnyCable in it?!

Without further ado, Sebastian’s story:

About us

LiveVoice is an ultra-low-latency audio streaming SaaS platform, used mostly for simultaneous interpretation, guided tours, silent stages and audio description. What we do is basically transmitting audio and video from one point of the Earth to another with as little delay as possible (~0.2s), coupled with a friendly UI and tons of other features.

With LiveVoice, you can set up events and channels and invite your speakers and your audience. The speakers and the audience can then use our mobile apps or the website to simply join the event and speak / listen to your channels. You can imagine it a bit like Skype or Zoom, but instead of many people talking to each other, only one person speaks and thousands of people listen to them.

Our setup

Not only do we have to transmit audio/video data very fast to a lot of people, we also have to do a ton of signaling. For example, if a speaker presses the "mute" button, we need to inform the whole audience to display the muted state. Ok, that is simple. But what about allowing one speaker to switch between different channels? Or allowing a speaker to take over a stream from another active speaker? How do we handle connection losses and reconnects? When it comes to live events, being reliable in those scenarios becomes more challenging quickly.

Our backend is built with Rails and we "grew up" using Action Cable. For listeners and speakers, we provide a web interface as well as native apps for Android and iOS. Regarding the apps, building them natively turned out to be the only viable option for us. Hence, we had to build our own native Action/AnyCable libraries in Kotlin and Swift. Right now, there are about 20 inbound message types and 35 outbound message types. To always guarantee compatibility with old clients, we introduced versioning for cable channels (and messages) on the server.

Challenge 1: Broken Connection Detection

Whenever a speaker loses the network connection, we have to inform the audience and the other speakers that the speaker went offline as fast as possible. Just think of a guided tour in a city, where people walk around, having an unstable internet connection. For us, the (almost) instant, server-side detection of those broken connections is of utmost priority.

Since Rails does not support this kind of server-side broken connection detection as of now (although there are promising PRs), a couple of years ago, we introduced our own version of a "pong". Every time a client received a "ping" from the server it responded with a "pong" back to the server. We also implemented a timeout using periodic timers and patched Rails to accept a "pong" format, similar to "ping". Using this workaround, we could set speakers who timed-out to offline within a couple of seconds.

As we wanted to migrate from ActionCable to AnyCable, we tried out different approaches to migrate or circumvent that pong feature, but got stuck. Evil Martians to the rescue! We reached out and you (editor’s note: Martians) implemented that pong feature directly into AnyCable server. Exactly what we needed; even better because terminating the command in Go without the need of RPC is super performant.

Since we were already using the AnyCable JS client library before even migrating our backend to AnyCable, we did not even had to implement the client side "pong" responses in the web client, we just had to enable them.

Challenge 2: Tidy up!

I think, one very common pitfall when using cables is that code often looks like it should happen synchronously, but in fact happens asynchronously. For example:

stream_from("my_stream")
ActionCable.server.broadcast("my_stream", { hello: :world })
stop_stream_from("my_stream")

Does the client receive the message? Well, it’s random, depending on when the broadcast is done (note that the behaviour of Action Cable and AnyCable regarding when streams are subscribed differ). Take another example:

ActionCable.server.broadcast("my_stream", { hello: :world_1 })
ActionCable.server.broadcast("my_stream", { hello: :world_2 })

Both messages will be received by the clients without the guarantee of any particular order. AnyCable helps us here by allowing us to send broadcasts in batches making sure broadcasted messages are always sent in order, which increases reliability and reduces the need for workarounds.

Also, we occasionally found ourselves in the situation that the current user who performed an action needed to get another response from the server than all the other clients. For example, when a speaker switches the channel, we need to send a lot of information to this speaker but all other speakers should only get a very brief message that a switch happened. AnyCable's broadcast-to-other feature came in super handy here. Now we can send different responses to the current user and to all other users:

ActionCable.server.broadcast("my_stream", { type: :another_speaker_switched }, to_others: true)
transmit({ type: :special_response_for_current_speaker })

This allowed us to tidy up our responses, send fewer messages in general (which is also easier to debug and to test) and simplified our client-side code bases.

Challenge 3: Performance

When running a streaming service, load testing is one important part of what lets us sleep well at night. Thus, we implemented our own CLI load-testing tool, based on our iOS client libraries (in Swift). This is especially useful, because with our own libraries, we can test realistic-behaving LiveVoice clients without the need to implement them in tools like k6 or Selenium. Our simulated listeners join an event, press start/stop once in a while and are streaming real audio. When testing AnyCable, we found that 10K listeners only consumed approx. 6% of the server’s CPU —which was pretty much unheard-of for us 😁

Stack: AWS c6g.2xlarge instance (ARM64), Debian 12, Ruby 3.3 + YJIT, AnyCable 1.4 (via HTTP RPC, pongs enabled), Jemalloc 5.3, Rails 7.1, Puma 6.4, Redis 7, Nginx 1.22. Note, that this server does not handle the actual audio/video streaming or the database, but handles all the web traffic and API requests, as well as all websocket connections.

Outlook

We are super happy with migrating to AnyCable and we'll definitely continue to dive into all the features (and there are a lot!). Especially relevant to our use case are features like optimized messaging formats or multi-regional scaling. An exciting future ahead 🫡 and cheers to you, Evil Martians!

Highlights

AnyCable v1.5 is out! Grab yours here.

We are glad to announce our new release—AnyCable v1.5, which adds a simplified standalone pub/sub mode: no RPC, Socket.IO style. Other updates include whispering (broadcasts that do not touch backend) which is super useful for typing indicators, cursors and similar features.

Check out the release notes for more information or take a look at a couple of new demos:

• Minimal messaging Next.js app demonstrating public streams (Stackblitz)

• Using signed streams and whispering for type indicators in our To-do/chat Rails app (GitHub PR)

P.S. We recently announced AnyCable v1.5 at the SF Bay Area Ruby Meetup, check out the video (and don’t miss other talks from the meetup).

P.P.S. AnyCable+ now runs on v1.5, so you can take the new simplified abstractions for a spin with just a few clicks.

News

Laravel 11 brings Reverb

Laravel got its own official WebSocket server. The benchmarks look pretty cool, but let’s wait while we figure out the AnyCable story for Laravel.

Talks

Seven deadly Rails anti-patterns at SinCityRuby (or, the reason we didn’t publish our previous Monthly).

One of the sins mentioned in the talk is page refreshes (Turbo 8 feature). Wonder how it could be both good and evil? Check out the slide (sorry, no video was recorded).

Releases

turbo · 8.0.x

Turbo 8 is conquering the Rails world! Morphing, refreshes, view transitions, insta clicks. How do you like it?

Frame of curiosity: AnyCable Broadcasts

No, this is not a new feature announcement 😁 “AnyCable Broadcasts” is the name of our blog on Substack (this one). We decided to go all-in with Substack and use it for articles, case studies, screencasts, short notes, and this newsletter—a shared home for all AnyCable and realtime-related content we produce.

So, expect more emails broadcasts from AnyCable appearing in your inbox soon. Here is a teaser of our first Customer Column post arriving next week:

For now, let us share the Top-5 broadcasts we transmitted over the years and just re-transmitted to Substack:

Please, tell us what you think about our AnyCable Broadcasts idea and what would you like to receive through this channel!

Leave a comment

And here’s how to subscribe:

Subscribe now

Highlights

AnyCable+ is here!

We are introducing AnyCable+, a Software-as-a-Quick-Service product (yes, SaaQS) that helps you to get started with reliable real-time features with just a few clicks. (No worries! AnyCable remains open-source in its core, so we expect you to run it on premise as soon as you hit higher loads; but while you’re working hard on reaching this goal, we’d like you to worry less about managing a real-time server.)

Free for early users. We hope you'll try it out and share your feedback (you can always reply to this email to reach us).

ONCE Campfire is publicly available 🔥

The first ONCE project has been released and it’s a real-time chat application, Campfire. The ONCE model implies a one-time payment and on-premise installation. But what’s more important for our newsletter, you get access to the codebase and are free to learn from it or modify it to fit your needs.

For example, you can try replacing Campfire’s Action Cable with AnyCable and see if it boosts the performance (spoiler: it does). Just like I did 🙂.

News

Action Cable adapterization

A huge initiative on bringing Action Cable to the next level has just kicked off with this pull request. The initial PR is mostly code reorganization (housekeeping) but the number of possibilities it opens is amazing. You can learn more from the document.

Releases

turbo · 8.0.0-rc.3

Turbo 8 reached its third release candidate and the final release is just around the corner. We’ve talked a lot about its features in the previous issues, so we’re not going to repeat ourselves. Remember: morph responsibly!

AnyCable real-time starter kit

We launched the official Vercel template to deploy a Next.js application powered by AnyCable. Combine it with AnyCable+, and you have a full-featured real-time application in minutes for free!

Frame of curiosity: channels vs. streams

One of the distinguishing features of Action Cable (and AnyCable) is encapsulation of real-time interactions into channels. The actual pub/sub is hidden from the client. Let me demonstrate what I mean by comparing two Rails chat implementations: one using Action Cable and another one using Pusher (well, it’s still popular 🤷‍♂️).

Here is the Action Cable version (showing only the relevant parts):

# A Stimulus controller used to subscribe to updates
export default class extends Controller {
  connect() {
    const channel = "ChatChannel";
    const id = this.data.get("id");

    this.channel = cable.subscriptions.create(
      { channel, id },
      {
        received: (data) => {
          this.handleMessage(data);
        },
      }
    );
  }

  handleMessage(msg) { ... }
}

# A server-side channel
class ChatChannel < ApplicationCable::Channel
  def subscribed
    room = user.chat_rooms.find_by(id: params[:id])
    return reject unless room
    stream_for room
  end
end

# An example of publishing an event
class MessagesController < ApplicationController
  def create
    message = @room.messages.create!(message_params)
    ChatChannel.broadcast_to(@room, message.as_json)
  end
end

And here is the same functionality backed by Pusher:

export default class extends Controller {
  connect() {
    const id = this.data.get("id");

    this.channel = pusher.subscribe(`chat:${id}`);
    this.channel.bind("message", this.handleMessage.bind(this));
  }

  handleMessage(msg) { ... }
}

class MessagesController < ApplicationController
  def create
    message = @room.messages.create!(message_params)
    pusher.trigger("chat:#{@room.id}", "message", message.as_json)
  end
end

The Pusher version is more concise and, frankly speaking, easier to digest: it’s clear what happens at both ends of this feature. We manage pub/sub channel directly, i.e., we subscribe to the same string identifier as we use to publish updates. There is nothing in between.

This communication design is used by most real-time frameworks. Why is Action Cable designed differently? I don’t know (I’m not the author), but I can see some benefits in using channels, especially in Ruby on Rails. They’re all hidden in the differences.

In Action Cable, we have to define a channel class that acts as a middleman between a client and a server. What may seem like an unnecessary boilerplate is actually a great way to organize logic around the communication channel. If you go beyond a demo application, you quickly realize that you need to deal with security (authentication, authorization) and maintainability concerns.

Let’s consider stream authorization. How would you implement it with a channel-less pub/sub? For example, Pusher asks a subscription permission from your application over HTTP. And then you need to write something like this:

class PusherAuthController < ApplicationController
  before_action :authenticate_user!

  def auth
    channel_name = params[:channel_name]
    if current_user_has_access?(channel_name)
      response = Pusher.authenticate(params[:channel_name], params[:socket_id])
      render json: response
    else
      render json: { error: 'Unauthorized' }, status: :unauthorized
    end
  end

  private

  def current_user_has_access?(channel_name)
    case channel_name
    in /chat:(?<id>\d+)/ if $~ in {id:}
      ChatRoom.find(id).members.where(id: current_user.id).exists?
    in /some_other_channel/
      # ...
    end
  end
end

Oops! That’s a lot of code (we had a single line for that in our channel class). Furthermore, imagine having a dozen of different streams with their specific authorization logic. You’ll probably end up with a custom abstraction to keep pub/sub authorization code maintainable. Maybe, even channels 🙂 (That’s how Laravel Echo and Elixir Phoenix work, for example).

Pub/sub encapsulation also makes it dead simple to subscribe a client to multiple data streams within the same subscription without even letting the client know about this. Here is an example:

class ChatChannel < ApplicationCable::Channel
  def subscribed
    room = user.chat_rooms.find_by(id: params[:id])
    return reject unless room
    stream_for room

    # Additional stream for moderator updates
    stream_for([room, :moderators]) if room.moderator?(user)
  end
end

Note that we don’t use string stream identifiers but pass Rails models instead. This is truly Rails way of dealing with the naming and consistency problems! Don’t argue which delimiter to use, “:” or “/”, just use what Rails suggests! That reduces the conceptual complexity of your codebase.

The last but not the least reason to choose channels over bare pub/sub is their RPC capabilities. With channels, handling client messages is straightforward; you have the channel and connection context and scope; and you have a file in your codebase where to put the logic!

So, encapsulation rocks. But what about Hotwire? Doesn’t it call into question everything I said above? Yes, it does. Hotwire demonstrates how to take another step further away from implementation towards abstractions. No more channels, no more JS. Now we have a pub/sub wrapped into Action Cable channels!

Still, even with Hotwire, if you want to implement a more sophisticated real-time logic, you can go with custom Action Cable channels (see examples in this talk). But that’s rarely needed. Authorization is covered by signed streams, no need for multiple streams and RPC.

That makes me think that having a generic secure pub/sub over Action Cable similar to Hotwire would be a nice addition to the framework. What do you think?

Frames of future ⏳

AnyCable+

Recently, a Gemfile of the new AnyCable project “leaked” online. The codename is “AnyCable+”, and it’s clearly a Rails app. But what is it for? Although we are eager to share everything with you right now, let us intrigue you a bit longer.

Action Cable server adapterization project

Together with Samuel Williams (who shared this diagram on Twitter), we started working on Action Cable improvements that would make it much easier to use different server implementations (e.g., Async) and even paradigms (like AnyCable) with Rails Action Cable.

Laravel Reverb

It looks like Laravel’s real-time component, Echo, will soon have an upgrade. The project named “Laravel Reverb” is expected to be released soon. What the next-gen real-time for PHP will look like?

SolidCable

Haven’t heard about it? Me neither. But who knows what DHH has up his sleeve. (Btw, check out his latest interview for our Dev Propulsion Labs).

News

Action Cable features in development

At the end of the year, the number of feature PRs to Action Cable spiked (compared to previous years, which were pretty quiet). Noticeable contributions (yet-to-be-merged) include pong support (to improve half-open connections detection) and broadcast payload compression for the PostgreSQL adapter (to overcome the 8kb limit).

More PRs are to come in 2024 from Honestly Yours regarding different server implementation support (such as Async). Stay tuned!

Posts

Replacing WebRTC. The long path to use something else for real-time media.

The article provides an excellent overview of new web technologies to bring next-gen real-time streaming experience and capabilities to browsers, including WebCodecs and WebTransport. Check it out to learn how we will write real-time applications (not only media-related) in a couple of years.

Turbo 8 in 8 minutes

We’ve been talking about Turbo 8 for a while. Now, when the first beta has been released, you can try it yourself. And Brad’s post is a great starting point. 

Releases

turbo-rails · 2.0.0-beta.1

A companion update for Turbo 8 beta.1 bringing page refreshes support to Rails. (Think twice before adding broadcasts_refreshes to your model: it publishes an update on every change, which you might not want).

Frame of curiosity: Advent of real-time code 🗓️ 🎅

Every December, millions worldwide participate in advent-calendar-driven challenges in anticipation of Christmas (or just for fun). Modern challenges vary from eating chocolate to collecting Lego figures, drinking coffee and tea, and solving programming puzzles. Let’s focus on the latter ones.

Advent of Code is the most prevalent challenge among software engineers (it has already started, but it’s never too late to join). However, there are many other coding challenges for you out there. For example, we have Advent of Prism (a new Ruby parser) in Ruby world.

I asked myself what a version of Advent of Code focused on the real-time web looks like and started sketching possible challenges. I’m unsure if I will ever make it live (maybe next year?), so I’d like to share some of my favorites with you.

Day 1. tail + cURL = real-time logs

You want to share your production server logs in real-time with another developer who has access to a headless Unix machine with only the essential CLI tools. You have access to a production machine and can write a program in the language of your choice. Write a program that accepts a stream of logs via standard input (Unix pipes) and exposes them over HTTP to the outside world so that you can consume them via cURL:

tail -f production.log | ./my-server

curl -N "http://my-server-ip/logs"

Day 2. Rock, Paper, Scissors, Lizard, Spock

Implement a terminal, HTTP-driven Rock, Paper, Scissors, Lizard, Spock game. Players issue HTTP requests with the same game ID and their choice to the real-time game server, and as soon as both players send their requests, the server responds to both with the result:

Keep in mind that there could be multiple concurrent games.

Day 3. ABC duel

Let’s build a 2-player real-time game called “ABC Duel”. Players open a page and press “Start”, as soon as both players enter the room (there could be multiple rooms), the server starts showing letter sequences on the screen. The first player to type the sequence correctly wins the round. There are 9 rounds in total.

Use WebSockets for client-server communication (in both directions) to minimize the latency.

...

Day 10. Dance in sync

Build a collaborative music listening application prototype. One user is a DJ (can pause/resume/seek audio), and others are listeners. Audio is synchronized for everyone…

… and so on.

P.S. Please let me know if you would like to take part in such a challenge next year and share your ideas!