---
title: "WebSockets"
description: "25 posts about WebSockets, summarised, each linking to the original."
---

# WebSockets
> 25 posts about WebSockets, summarised, each linking to the original.

## Articles

### [How We Got to LiveView](https://yomu.fyi/post/how-we-got-to-liveview.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Sep 22, 2021
- Type: Explainer

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](https://yomu.fyi/post/building-a-distributed-turn-based-game-system-in-elixir.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Apr 29, 2021
- Type: Tutorial

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](https://yomu.fyi/post/low-latency-liveview.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: Apr 5, 2021
- Type: Explainer

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](https://yomu.fyi/post/websockets-and-fly.md)
- Company: [Fly.io](https://yomu.fyi/company/fly-io.md)
- Published: May 20, 2020
- Type: Tutorial

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](https://yomu.fyi/post/short-time-outs-and-asynchronous-requests-on-heroku.md)
- Company: [Heroku](https://yomu.fyi/company/heroku.md)
- Author: Damien Mathieu
- Published: Dec 5, 2014
- Type: Explainer

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.


[Newer posts](https://yomu.fyi/topic/websockets.md)