Sanity CMS development, where the schema and the query decide everything else.

Editors want few fields, plain names, sensible defaults and a preview that identifies a document without opening it. A render layer wants narrow types it can switch on. The two pull apart in the page-builder array first. Thirty block objects turn every route into a union the front end defends forever, and two of those thirty are hero variants that differ by a background colour. Content belongs in the schema, layout in the front end.

The spread operator inside a projection returns every attribute of every matched document, so a listing that wants a title, a slug and an image ships the full Portable Text body of each entry. Filter, order, slice, then project explicitly, dereferencing with the arrow only into a sub-projection that names its own fields. Query length matters too. Past a point the client falls back to POST, POST is not cached, and a route you thought was a CDN read now hits the live Content Lake every time.

Portable Text is an array of blocks. Each block holds children spans, each span holds marks, and a mark is either a simple decorator or a key pointing into that block’s markDefs. A renderer that assumes marks carry their own data handles bold and italic perfectly and drops every internal link. Give the components map an explicit fallback, because the default for a forgotten type is to render nothing, and nothing looks identical to an empty field.

The standard wiring is a GROQ-powered webhook that fires on a change and revalidates a tag. It’s wrong twice over. A webhook tells you which document changed, not which pages render it, so renaming an author leaves two hundred posts showing the old byline. Tag by type as well as by id, and resolve the affected routes with a reverse-reference query. Worse, the webhook can arrive before the API CDN has the new document, so revalidating through the CDN re-caches the exact thing you were replacing.

Structure builder replaces the default document lists with panes matching how your team works, input components swap in where a plain string field misrepresents the data, and document actions bend to a real editorial process. What stops is the server. No hook runs before a document is written and no beforeChange enforces an invariant for every client, so validation is advisory to anything holding a token. Access control is granular on the higher plans and coarse below them, so settle the plan before you settle the model.

Sanity wins when several people edit the same content at once, when nobody wants to operate a database or a CMS server, and when one body of structured content feeds a website, an app and an email system. Payload wins when content and application data belong in one Postgres database, when hosting has to be self-managed, or when access rules have to be enforced server-side. Our Payload CMS development page argues the other side in the same detail.