No backend. The database is the API.
You don't write CRUD APIs on The Grid. You don't maintain a user database. You define schemas, capability rules, and event triggers — the protocol does the rest. Apps compose from DEFs (Edge, Store, Compute, Vault, Keys…) and settle per-receipt on-chain. See the data model →
What disappears
Building on The Grid means deleting categories of code you wouldn't have to write in the first place. The protocol owns them.
No HTTP API layer
No /api/v1/posts. Apps read and write def:dsf/state directly with capability tokens.
No user database
The user owns their rows in their vault. You scope access by path pattern and trigger functions on data events.
No auth implementation
Grid Auth (OAuth-2.1-compatible) wraps DIDs + capability tokens. No password storage, no OAuth dance to roll.
No payments integration
def:eco settles every request as a signed receipt. Verifiable on-chain. No Stripe webhooks to plumb.
Anatomy of a Grid app
A real app is a composition of DEFs. A blog uses def:dsf/content (assets) + def:dsf/state (post metadata) + def:nie (edge serving) + def:ind (DID resolution) + def:eco (settlement). The composition pattern is the programming model.
A static site
def:nie + def:dsf/content + def:paas. Edge cache, custom .grid name, free for the first 10M requests.
A full app
def:nie + def:dsf/state + def:xsr + def:ind. User-owned data, capability-scoped reads/writes, no backend code.
An API endpoint
def:xsr WASM function. Capability-token auth instead of API keys; per-call settlement on-chain.
An AI agent
def:xsr/infer + def:dsf/state for memory. Every action issues a receipt — agentic compute is metered and auditable.
Three steps
Install the CLI
$ npm i -g @grid/cli $ grid login
Deploy
$ grid deploy ./ → live in 30s
Watch receipts land
$ grid receipts tail → 142 req · $0.0042