Adapters
An adapter is a protocol front door. Your client speaks the wire protocol it already knows — Convex, Firestore, Cloud Functions, MongoDB, DynamoDB, or the native API — and Nimbus serves it from the same engine, storage layer, and tenant boundary as every other surface. Picking a door changes the shape of your calls, not where your data lives or how it is isolated. The design and its limits are explained in the adapter boundary.
How the surfaces are served
Section titled “How the surfaces are served”Every server serves these surfaces by default. The Convex-compatible surface,
the Firestore routes, and the native API share the main listener; MongoDB and
DynamoDB each bind their own conventional port (127.0.0.1:27017 and
127.0.0.1:8000).
nimbus dev wires your app automatically, and it treats two kinds of surface
differently.
One app adapter. The adapter that owns your app’s wiring, codegen, and watch loop is singular — exactly one is chosen:
| Nimbus sees | App adapter |
|---|---|
a convex/ directory | Convex |
a firebase dependency | Firestore |
a firebase.json | Cloud Functions |
Any number of wire surfaces. These are a set, and they compose with any
app adapter — a Convex app that also installs mongodb keeps its Convex dev
loop and gets the MongoDB listener:
| Runtime dependency | Wire surface |
|---|---|
mongodb or mongoose | MongoDB — writes NIMBUS_MONGODB_URL to .env.local |
@aws-sdk/client-dynamodb or @aws-sdk/lib-dynamodb | DynamoDB — writes NIMBUS_DYNAMODB_* to .env.local |
@aws-sdk/client-s3 or @aws-sdk/lib-storage | S3 |
Wire-surface detection reads only the runtime dependencies in your
package.json — not devDependencies, optionalDependencies, or
peerDependencies — because enabling one starts a listener, generates
credentials, and writes .env.local. A bare aws-sdk (v2) dependency is too
broad to imply DynamoDB or S3, so it only produces a banner hint and never
enables a surface.
The Firestore, MongoDB, DynamoDB, and S3 surfaces can each be switched off with
nimbus start flags (--no-firestore, --no-mongodb, --no-dynamodb,
--no-s3); the Convex-compatible surface and the native API are always on.
Under nimbus dev a wire surface is enabled by its runtime dependency (above)
rather than a flag — remove the dependency to leave it off. Flags, ports, and
credentials are in configuration.
Which surface should you reach for?
Section titled “Which surface should you reach for?”| Surface | Reach for it when | You write against | Migration guide |
|---|---|---|---|
| Convex | you want the full function model — queries, mutations, actions, and reactive subscriptions | convex/ functions and the Convex clients | Yes |
| Firestore | you have a Firebase app, or want Firestore’s document SDKs | the stock firebase/firestore SDK | Yes |
| Cloud Functions | you are porting Cloud Functions for Firebase workloads | firebase-functions v2 handlers | Yes |
| MongoDB | you already have code on the official MongoDB drivers | your existing MongoDB driver | — |
| DynamoDB | you already have code on the AWS SDK | @aws-sdk/client-dynamodb | — |
| Native API | you want any language, with no SDK | plain HTTP and WebSocket | — |
The ported-source surfaces (Convex, Firestore, Cloud Functions) carry a migration guide because you are moving existing source onto Nimbus. The driver surfaces (MongoDB, DynamoDB) and the native API need no migration — you point an existing client at a Nimbus endpoint and keep your code.
Every surface ships runnable examples: Convex, Firestore, Cloud Functions, MongoDB, DynamoDB, and Native API.
Compare what each one supports
Section titled “Compare what each one supports”Surfaces are not interchangeable: each translates a different slice of the engine. Adapter capabilities puts all six side by side — CRUD, queries, indexes, subscriptions, transactions, schema validation, auth, tenant binding, and default ports — with links into each per-surface reference. The full per-surface compatibility matrices live in the Reference section.
Other wire surfaces
Section titled “Other wire surfaces”Nimbus serves protocol surfaces that are not app front doors and have no
guides in this section: an S3 API (wired by
nimbus dev when you declare an AWS S3 client, as above), a
Cloudflare-compatible Workers KV
plane, and a RESP (Redis) listener started
with nimbus kv. Each is documented in the Reference section with its own
maturity caveat.