Running in memory
Because the two extension points — event bus and storage adapter — both have in-memory implementations, a complete datadata stack runs in a single JavaScript process: real server, real clients, real optimistic updates, with microtask latency and no infrastructure.
What it’s for
Section titled “What it’s for”- Server-side agents. The production use: in-process clients attach agents directly to the server inside the Durable Object, alongside WebSocket users.
- Tests. datadata’s test suite spins up real client/server pairs per test — multi-client convergence, conflict, and session scenarios run without mocks or network.
- Demos in the browser. The live demos on this site run the full engine in the page: several “clients”, one “server”, a latency slider standing in for the network. Nothing is simulated except the wire.
The one thing the in-memory stack leaves out is the blob
lane: a blob’s download URL is a plain string meant for <img src>, which no
in-process transport can serve, so the backendless client has no blob support
and its server refuses schemas that declare blob fields.
The local mode isn’t a mock
Section titled “The local mode isn’t a mock”It’s easy to make a sync engine that only works distributed (everything needs the real backend) or one whose local mode is a mock that lies to you. Keeping one event vocabulary and one server core for both is what makes the in-memory mode faithful — what you observe in a test or a demo is the production code path, minus TCP.