zmdbzero-maintenance data layer
Docs Benchmarks Anti-patterns OpenAPI
Docs / Ecosystem integrations

GraphQLNot planned

Not planned. This capability had a frozen design and will not be built — the page stays so the answer is findable, and so is what to reach for instead. out of scope — run a GraphQL server next to the application instead

Not planned. @zmdb/web supports HTTP, WebSockets, and SSE, but it does not include a GraphQL layer. The related epics are closed as wontfix. These pages preserve the design notes and show how to compose an external GraphQL server with zmdb when needed.

How it would have sat on the existing seams#

The design was frozen before the capability was dropped — packages/schema/src/sdl/SPEC.md for the type half, packages/web/src/graphql/SPEC.md for the resolver half — and it was an emitter + a resolver registry over DI:

Code-first only; an SDL _consumer_ is refused.

by implements ResolversOf<F>.

behaviour is an Interceptor (@deprecated is the only one emitted), and query cost is a function your transport calls between parse and execute.

Why it is not being built#

The spec is frozen; the code will not be written. GraphQL is a large surface — SDL emission, resolver binding, dataloader batching, subscriptions, federation — and each of those is a maintenance surface that has to keep answering identically to the REST derivation beside it. The project would rather derive one API well than two, so the surface is excluded rather than deferred.

If you want GraphQL over a zmdb application, run a GraphQL server next to it: your services are plain objects and a schema library can call them directly, which is what Resolvers & Mutations shows end to end. Nothing zmdb ships serves POST /graphql, and nothing will — the transport, and with it your authentication model, stays yours.