Loading…
Topic
WebSockets
25 posts about WebSockets. Every summary links to the original.
- 25 posts
- 5 companies
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
Newest first
Posts
How We Got to LiveView
Chris McCord recounts how Phoenix and LiveView emerged from attempts to make real-time features as simple as Rails CRUD development. He first built sync.rb, which used WebSockets to re-render server-side templates and push HTML updates without requiring programmers to write JavaScript, but Ruby’s concurrency model and EventMachine proved unreliable for the task. He then turned to Elixir and the Erlang VM, whose lightweight message-passing processes and fault tolerance supported Phoenix Channels and a reported load test of 2 million concurrent WebSocket connections on one server. LiveView unifies client and server state in a stateful process that synchronizes only necessary HTML changes. The account also describes binary uploads, WebSocket-based navigation via live_redirect and live_patch, and HEEx, an HTML-aware Elixir template syntax with compile-time validation.
Building a Distributed Turn-Based Game System in Elixir
Mark Ericksen describes building a proof-of-concept distributed, clustered game system for turn-based multiplayer applications with Elixir and Phoenix LiveView. Rather than separate JavaScript and API layers or external state systems such as Kafka and Redis, the design uses server-rendered HTML over websockets, Phoenix.PubSub, and Horde’s distributed process registry. A player’s LiveView sends moves to a GameServer, which publishes updated game state so subscribed LiveViews re-render for every connected player; Tic-Tac-Toe supplies the model. Hosted on Fly.io, geographically close web servers connect over a private WireGuard network while a game’s single GameServer remains the source of truth, with libcluster handling cluster formation and healing. The resulting open-source proof of concept supports multiplayer games, four-letter game codes, on-demand creation, responsive updates, and globally clustered servers.
Low Latency LiveView
LiveView sends HTML fragments over a WebSocket connection, allowing Phoenix applications to update the DOM in response to server or user activity. For interactions such as a like button, however, a server round trip can make feedback feel slow: a sub-100ms sequence may be acceptable, while many interactions benefit from responses under 40ms. The post presents client-side state prediction as one remedy, where the browser displays an expected value immediately and later reconciles it with the server. Its preferred “boring” alternative is reducing round-trip time by running application processes near users in multiple cities, connecting Phoenix instances over a private network and enabling clustering. A seven-region Counter deployment is shown with fly regions set and fly scale count 7, while Phoenix.PubSub and Phoenix.Presence handle clustering transparently.
WebSockets and Fly
Fly supports WebSocket connections, and the post demonstrates that support with flychat-ws, a small chat application built from raw WebSockets and Express. Deployment requires cloning the example, running npm install, then using flyctl init, flyctl deploy, and flyctl open, with no application-specific configuration changes. Its fly.toml maps internal TCP port 8080 to HTTP port 80 and TLS/HTTP port 443, sets concurrency limits of 20 soft and 25 hard, and checks the service every 10 seconds with a two-second timeout. The Node server broadcasts each received message to every connected client, while the browser selects ws or wss from the served protocol and sends JSON messages. TLS terminates at Fly’s network edge, and the app can also run locally or in Docker.
Short Time Outs and Asynchronous Requests on Heroku
Heroku’s short request timeout and H12 errors reflect a scaling problem: standard web servers process queued requests serially, so one long operation can block others. The post separates slow server-side actions, such as video processing or PDF generation, from file uploads, and recommends background processes for the former and direct browser uploads to Amazon S3 or Google Cloud Storage for the latter. When a client must wait for completion, it describes polling or a WebSocket, noting that WebSocket connections close after 55 seconds of inactivity and ordinary pages still need to respond within 30 seconds. Avoiding lengthy web-process work improves performance and scalability; rack-timeout for Ruby or expressjs’ timeout for Node can terminate requests after a few seconds, with a recommended limit no higher than 10 seconds.
Related topics
All topics →Weekly digest
The best engineering reads, once a week.