How websockets work in Base

Most of a worker's life is request and response: a client asks, the worker answers, the connection closes. Websockets are the exception, a connection that stays open so messages can flow both ways over time. Live updates, chat, anything where the server needs to push rather than wait to be asked. Base supports websockets and, on Cloudflare, ties them to the platform feature that makes long-lived connections actually work at the edge.

The shape of a websocket in Base

A websocket connection is long-lived, so the model is different from a route. Instead of a handler that runs once and returns, you have a connection that opens, carries messages in both directions for a while, and eventually closes. Base gives you a delegate to handle that lifecycle: the points where a connection is established, where a message arrives, and where it closes. You declare websocket support in your settings and provide the handling for those moments, and Base manages the connection machinery underneath.

Messages are the unit. A client sends one, your worker reacts and can send messages back at any time while the connection is open, not only in response to a specific incoming message. That is the whole reason to use a websocket: the server can speak first.

Why Durable Objects are part of the story

A long-lived connection needs somewhere stable to live. A plain Worker is built to handle a request and go away, which is the opposite of holding a connection open and tracking who is connected. On Cloudflare, the feature that provides that stable, stateful home is the Durable Object, and Base bridges websockets to it.

This is why the websocket and the Durable Object posts are related. The Durable Object gives a connection (or a room full of connections) a consistent place to be coordinated: one object that owns the connected clients and their shared state. Base's bridge connects the websocket layer to that object, so "a worker that holds open connections and coordinates them" becomes something you configure rather than something you architect from scratch. Base also supports websockets in a Node setting, but the edge story runs through Durable Objects.

Websockets and RPC

Base also lets RPC run over a websocket, not just over a fetch-style request. When a call goes over a persistent connection instead of a fresh request each time, you keep the typed-procedure feel of RPC while gaining the open channel of a websocket. For an application that is already making typed calls and also wants live, push-style interaction, that pairing means one model rather than two.

The mental model to keep

A websocket in Base is a long-lived, two-way connection handled through a delegate for open, message, and close, declared in your settings like any other capability. On Cloudflare, it leans on Durable Objects to give those connections a stable, coordinated home, which is why the two features are studied together. And RPC can ride over a websocket, so typed calls and live push can share one channel. Reach for websockets when the server needs to speak first; reach for routes when the client always asks first.