In-process clients

datadata’s client and server are connected by an event bus abstraction, not by a socket. One implementation routes events over WebSockets; another — the in-process event bus — dispatches them as plain function calls within a single JavaScript process.

A real client, no network

connectInProcessClient wires a full client to a full server in the same process. It is not a mock: the same optimistic-update machinery, the same validation, the same event ordering — just with microtask latency instead of network latency.

Server-side agents

The motivating use: an AI agent running next to the server (in the same Durable Object, in the current deployment) as a first-class client. A composite event bus lets in-process clients and WebSocket clients coexist on one server — so the agent stages edits through an in-process session while humans watch the same live documents from their browsers, each seeing the other’s changes in real time.

The server also exposes a change callback — a hook invoked on every accepted write — which is how agent-triggering, auditing, and downstream automation attach without polling.

Syncing with data outside the folder

A folder is the unit of authority — one server owns it and orders its events. Applications routinely need it reconciled with data that lives elsewhere: your main application database, an external API, a system of record that predates the folder.

Getting history out needs no client — that is what portable event streams are for, a one-way replay into another store. Getting changes back in is what needs one. Writes from outside have to enter through a client, so they are validated, ordered and broadcast like anyone else’s.

Where that bridge runs decides what it can see. Outside the folder it connects over a WebSocket, the same way a browser does — and like a browser it subscribes per document, so it only learns about documents it already knew to watch. Inside the folder’s own server process it can register server.onDocumentChange instead: one hook, every accepted write in the folder, subscribed or not. That, rather than the absent socket, is why a mirror wants to run in-process.

The mapping between your documents and your tables stays application-specific. datadata supplies the client and the callback, not the bridge.

Tests and demos

The in-process bus is also why datadata is easy to exercise: the test suite runs real client/server pairs with no infrastructure, and the live demos planned for this site will run the same way — a complete sync engine, client and server, inside your browser tab.