Design an admin CMS

Requirements: one app, forty content types

A CMS (content management system) is the app people use to create and change the content a website or app shows. An admin CMS is the internal side of it: a back office where editors, not readers, do their work. Strapi, Sanity Studio, the Contentful web app and Django admin are all versions of the same idea.

A headless CMS stores content and serves it over an API, and some other app (the public site, a mobile app) renders it. Our design is the editing UI, whether the content is shown by our own site or by many.

Every screen in such an app is one of two shapes. A list view shows many entries of one type in a table, with search, filters and bulk actions. A detail view shows one entry as a form you edit and save. With 40 types, each with its own fields and more every quarter, the core question of the whole design is: who builds those 80 screens?

Questions to ask

Each question below changes a real decision later in the guide. The middle column is what this guide assumes.

Functional requirements

• Navigate between content types in a sidebar; open a list view per type.
• List views: server-side pagination, sorting and filters, all stored in the URL; saved views; select rows and run bulk actions such as publish, archive or delete.
• Detail views: a form generated from the type's schema, with field validation, relation pickers, rich text, media fields, and an unsaved-changes guard.
• Drafts and publishing: save a draft, publish now or at a scheduled time, preview a draft on the real site, see and restore older versions.
• Safe concurrent editing: never silently overwrite another editor's work.
• A media library: upload, crop around a focal point, require alt text, see where an asset is used before deleting it.
• Permissions per role, per content type and per field; a history of who changed what.
• Developers can add custom field components and dashboard widgets without forking the app.

Non-functional requirements

• A list view shows its first page in under 1 second on office Wi-Fi, and a page change, sort or filter takes under 500 ms at the 95th percentile.
• A detail form for a 120-field type is usable in under 1.5 seconds after a click from the list.
• The JavaScript for the shell stays under 250 KB compressed; field editors such as rich text or a map picker load only when a form needs them.
• No silent data loss: not from a closed tab, not from a second editor, not from a failed save.
• Fully keyboard operable and usable with a screen reader, including complex fields. Internal tools still fall under accessibility law in many countries, and some editors rely on assistive technology.
• The server enforces every permission; the UI only reflects them.

Out of scope

• The schema builder UI (a drag-and-drop editor for content types). Our developers write schemas as code, so we only consume them.
• Real-time co-editing of the same field, Google Docs style. Editors work on different entries almost all the time; we cover the rare overlap with conflict detection and presence instead.
• How the public site renders content and caches it, except where preview touches it.
• Workflow engines with many approval stages. We support draft, review and published, and mention where a richer workflow plugs in.

What makes an admin CMS hard

An admin CMS looks boring: tables and forms. The difficulty is not in any one screen. It's in five properties that every screen shares, and each one drives a later chapter.

1. Many shapes, one app. 40 content types with different fields, growing every quarter. If each new type needs a frontend release with two new screens, the frontend team becomes the bottleneck for the whole company. The UI has to be data: generated from a schema at runtime.
2. Long-lived, valuable edits. An editor may spend 40 minutes on one landing page. Losing that work to a closed tab, an expired session or another editor's save is the worst bug this app can have. Every save path needs a failure story.
3. Two versions of the truth. Every entry has a draft that editors change and a published version readers see. Scheduling, preview and version history all come from keeping those apart cleanly.
4. Huge lists. 400,000 articles and 30 million orders mean the list view is a window onto a server query. The URL, the API and the table must agree on what that query is.
5. Uneven trust. A staff editor, an agency freelancer and a translator see the same app with different powers, down to single fields. The UI must reflect permissions honestly, while the server enforces them.

Notice what is not on the list: rendering speed of a single view, real-time feeds, offline mode. An admin CMS is a correctness problem first and a performance problem second. A senior answer spends its minutes on schemas, saves and conflicts, not on virtualizing a 50-row table.

Schema-driven UI: screens as data

Start with the naive plan: a developer builds a list page and a form page for each content type, by hand, in React. For the first 3 types this is the best UI you can get. By type 40 it's a trap: if each new type costs about 2 days of frontend work, 5 types a quarter is 10 days of a developer doing copy and paste.

Worse, the copies drift: the FAQ form warns about unsaved changes and the Author form doesn't, because someone forgot. Every fix to shared behavior has to be applied 40 times.

The way out is the idea from the config-driven-ui lesson: describe each type once as data, a schema, and let generic components turn that data into screens. A schema here is a description of a content type: its fields, each field's type (text, number, date, enum, relation, media, rich text), its validation rules, and a few hints for the UI.

What a schema looks like

The schema says what the data is and gives the UI a few hints. It doesn't say how a text input looks. That keeps it usable by the server too: the same file drives the database columns, the API validation and the admin screens.

export const article = defineType({
  name: "article",
  label: "Article",
  titleField: "title",
  fields: [
    { name: "title", type: "string", required: true, maxLength: 120, localized: true },
    { name: "slug", type: "slug", from: "title", unique: true },
    { name: "category", type: "enum", options: ["news", "guide", "opinion"] },
    { name: "author", type: "relation", to: "author", required: true },
    { name: "tags", type: "relation", to: "tag", many: true, max: 8 },
    { name: "hero", type: "media", accept: ["image/*"], altRequired: true },
    { name: "body", type: "richText", localized: true },
    { name: "displayDate", type: "datetime" },
  ],
  // status (draft, published...) and updatedAt are system fields every type has
  list: { columns: ["title", "author", "status", "updatedAt"], defaultSort: "-updatedAt", paging: "cursor" },
  form: { tabs: [
    { label: "Content", fields: ["title", "slug", "hero", "body"] },
    { label: "Meta", fields: ["category", "author", "tags", "displayDate"] },
  ] },
});

The field registry: one entry per field type

The generic views never contain a switch over field types. They ask a field registry: a map from field type to the four things every screen needs from it. A list needs a Cell, a form needs an Input, the filter bar needs a Filter, and everyone needs validate. Adding a custom type, say geoPoint with a map picker, means registering one more entry.

type FieldPlugin<V> = {
  Cell: React.ComponentType<{ value: V; field: FieldDef }>;
  Input: React.LazyExoticComponent<React.ComponentType<InputProps<V>>>;
  Filter?: React.ComponentType<FilterProps<V>>;
  validate: (value: V, field: FieldDef) => string | null;
  sortable: boolean;
};

registry.register("string", stringPlugin);
registry.register("relation", relationPlugin);
registry.register("richText", {
  ...richTextPlugin,
  Input: lazy(() => import("./fields/RichTextInput")),
});
registry.register("geoPoint", geoPointPlugin); // added by the stores team

Input is lazy on purpose. A full rich text editor with its extensions can add 100 KB or more, and a map picker more; a form that has neither should never download them. The performance chapter comes back to this.

From the schema, the app derives three things. List columns: the list.columns hint, or else the title field plus the first 3 short fields, plus updatedAt. Rich text, media and many-relations never become columns, because they don't fit in a cell.

Filters: one per field whose plugin has a Filter: an enum becomes a multi-select, a date becomes a range, a relation becomes a search picker, a boolean becomes a toggle. The form: tabs and sections from form, one Input per field, and a validator built by running every field's validate plus the schema rules (required, maxLength, max). Django admin follows the same idea with a ModelAdmin class, whose list_display, list_filter and search_fields options are hints of exactly this kind.

When generic stops being enough

Generated UI is great until the screen is a workflow rather than a record. Three real cases from back offices: an order page where the main action is "refund 2 of 3 items", not editing fields; a landing page builder where editors drag blocks and want a live preview beside the form; a dashboard that shows numbers, not entries. Forcing these into a field list produces screens nobody can use.

Order matters: always try the smallest hatch first. A custom view loses the shared behavior (the unsaved-changes guard, the conflict check, history) unless it rebuilds it on purpose. So the plugin API gives custom views the same form state hooks the generic form uses.

List views: a window onto a server query

The list view is where editors start every task: "find the draft article about pricing that Ana wrote last week". The data-table guide covers the table itself (columns, sticky headers, row selection, virtualization). Here we focus on what's specific to a CMS: the list is a server query generated from a schema, it lives in the URL, it can be saved, and it's the launch pad for bulk actions.

The query lives on the server and in the URL

The naive list fetches all entries of a type and filters in the browser. For FAQs (80 entries) that works. For articles it would download 400,000 rows, around 200 MB of JSON. So paging, sorting and filtering all happen in the database, and the client sends a description of what it wants.

That description is the list's real state, and as the url-as-state lesson argues, it belongs in the URL: a teammate can open the link, the back button undoes a filter, and a refresh lands on the same page.

/content/article?q=pricing&status=draft&author=usr_ana
  &updated=2026-10-12..2026-10-19&sort=-updatedAt&cursor=eyJ1IjoiMjAy

GET /api/entries/article?q=pricing&filter[status]=draft
    &filter[author]=usr_ana&filter[updatedAt][gte]=2026-10-12
    &sort=-updatedAt&limit=50&cursor=eyJ1IjoiMjAy

Filter names come from the schema, so the list can validate the URL before sending it: an unknown field or an operator the field type doesn't support (a range on an enum) is dropped and the URL rewritten with history.replaceState. That stops a stale bookmark from turning into a 400 error page.

Saved views

Editors repeat the same filters every day: "my drafts", "scheduled this week", "missing alt text". A saved view is a name plus the list's URL query plus the chosen columns. Because the state already lives in the URL, saving a view is just storing that query string on the server under the user (private) or the team (shared).

Opening a view navigates to the stored URL. Keep views on the server, not in localStorage, so they follow the editor to another laptop and so a lead can share a view with the whole team.

Bulk actions and partial failure

Select 50 rows, press Publish. The naive version fires 50 requests from the browser with Promise.all, and three things go wrong. If the tab closes after 20, the other 30 never happen and nobody knows. Promise.all rejects on the first failure, so the UI can't say which ones failed, and "select all 2,300 matching this filter" would mean 2,300 requests.

The better design sends one request that describes the selection: either a list of ids (up to a page) or the filter itself ("all matching"). The server creates a bulk job, returns 202 Accepted with a job id, and processes entries one by one, checking permissions and validation for each. The client polls the job (or listens on a server-sent events stream) and shows progress. When it ends, the result lists every failure with a reason.

{
  "id": "job_8f2",
  "action": "publish",
  "status": "done",
  "total": 2300,
  "succeeded": 2297,
  "failed": [
    { "id": "art_19", "code": "validation", "message": "Hero image is missing alt text" },
    { "id": "art_77", "code": "forbidden", "message": "You can't publish opinion articles" },
    { "id": "art_903", "code": "conflict", "message": "Locked by Ana Ruiz" }
  ]
}

Two details matter. When the filter is the selection, freeze it: the server resolves the ids when the job starts, so an entry that starts matching mid-job isn't silently published. And destructive actions (delete) take a confirmation that states the count in words, "Delete 2,300 articles", with the count typed back for anything above 100.

Forms: big, validated, and hard to lose

The detail view is a form generated from the schema. For most types it has 15 fields and is easy. The landing page type has 120, nested blocks, 8 relations and 3 rich text areas. Design for that one, and the small ones come for free.

Form state that scales to 120 fields

The naive form keeps every value in one useState object at the top. Each keystroke creates a new object and re-renders all 120 fields, including 3 rich text editors. On a mid-range laptop that can take tens of milliseconds per key, which you can feel as lag.

The form-state lesson covers the fix: a form store outside React (React Hook Form, TanStack Form, or our own small store) where each field subscribes only to its own value. A keystroke in the title re-renders the title input and the few things that watch it, like the slug preview.

The store keeps two copies of the entry: the baseline (what the server last returned) and the current values. Dirty state is the difference between them, per field. That one comparison feeds four features: a dot on each tab that has changes, the Save button's enabled state, the unsaved-changes guard, and the field list in the save request (send only changed fields, a PATCH).

Sections, tabs, and where errors hide

Tabs come from the schema's form.tabs. Tabs keep a 120-field form scannable, but they hide errors: the editor presses Save on the Content tab and the error is on the Meta tab. So each tab label shows a count of its errors ("Meta, 2 errors"), and on a failed save the form moves focus to an error summary at the top that links to each field, switching tabs when a link is followed. The multi-step-form guide builds that error summary in detail; reuse it as is.

Validation from the schema, twice

The schema rules (required, maxLength: 120, max: 8 tags, unique) compile into a validator that runs in the browser on blur and on save. The same schema runs on the server, which is the real judge, and some rules can only run there: unique slug, "the related author must be published". As the input-validation lesson says, client checks are for speed, never for safety. The server returns 422 with errors keyed by field path, like blocks.3.cta.url, and the form maps each path back to its input.

Relation pickers

A relation field links to entries of another type: an article's author, its 8 tags. There may be 3,000 authors, so the picker is a combobox that searches the server: type 2 characters, wait 200 ms, call GET /api/entries/author?q=an&limit=20&fields=id,title,avatar, cancel the previous request with AbortController. Each result shows the target type's titleField and status, so editors don't link a draft author by mistake.

Two extras save real time. "Create new author" opens a nested form in a side panel and links the result on save, and each chosen relation has an "Open" link to its own entry. The keyboard and screen reader rules come from the WAI-ARIA combobox pattern; the accessibility chapter lists them.

Rich text fields embed the editor from the rich-text-editor guide. The CMS adds one thing on top: the editor stores structured JSON (blocks and marks), not HTML, so the public site can render it anywhere and the history chapter can diff it.

Saving: explicit, optimistic, or automatic

useEffect(() => {
  function onKey(e: KeyboardEvent) {
    if ((e.metaKey || e.ctrlKey) && e.key.toLowerCase() === "s") {
      e.preventDefault();
      if (form.isDirty && !form.isSaving) void form.save();
    }
  }
  window.addEventListener("keydown", onKey);
  return () => window.removeEventListener("keydown", onKey);
}, [form]);

The unsaved-changes guard

Two exits need guarding. Closing or reloading the tab: listen for beforeunload and call event.preventDefault() while the form is dirty; browsers then show their own generic prompt (no custom text is allowed). Moving inside the app: the router must block navigation and show our own dialog with Save, Discard and Cancel. Register the beforeunload listener only while dirty and remove it after a save: web.dev's back/forward cache guide recommends exactly that, because the listener has made pages ineligible for that cache in the past and is still unreliable.

Drafts, publishing, preview and versions

Readers must never see half-done work, and editors must be able to change a live article without taking it offline. So every entry has two faces: the draft editors change and the published version the site serves. Scheduling, preview, history and restore all come from how those two are stored.

The UI shows the state from the two pointers, not from a stored flag. No published version: Draft. Draft equals published: Published. Draft newer than published: Changed (live, with newer edits waiting), the state editors most often misread.

The Contentful web app shows entries with these same three names, plus Archived: a flag for unpublished entries that hides them from lists and pickers without deleting them. Our header shows the state as a chip. When it reads Changed, two buttons sit next to it: "Publish changes" and "Discard changes" (which resets the draft to the published version).

Scheduled publishing across time zones

An editor in Berlin schedules a US sale page for "9:00 on Monday 2 November". Whose 9:00? The naive date picker uses an input type=datetime-local, which returns a string with no zone, and the code calls new Date(value), which reads it in the editor's own zone. The page goes live at 9:00 Berlin, 3:00 in the morning in New York.

Converting by hand is no safer. Europe leaves summer time on 25 October 2026 and the US on 1 November, so for that one week New York is 5 hours behind Berlin instead of the usual 6. Only a time zone database gets this right, which is why the zone travels with the time:

• The picker asks for a time and a zone, defaulting to the site's audience zone from the schema, not the browser's. Zones are IANA time zone names such as America/New_York, the identifiers browsers and servers share, which carry each region's daylight saving rules.
• The client converts the wall time in that zone to one UTC instant and sends it as ISO 8601: 2026-11-02T14:00:00Z.
• The confirmation shows both: "Mon 2 Nov, 09:00 New York (15:00 your time, Berlin)", formatted with Intl.DateTimeFormat and its timeZone option.
• The server runs the job. The browser never publishes on a timer: the editor's laptop may be asleep.
• The schedule pins a version. If the draft changes after scheduling, the header warns "Scheduled version is older than your draft" and offers to reschedule with the new one.

Preview drafts on the real site

A form can't show how a landing page will really look: the site's fonts, layout and components do that. So the editor needs the real site, rendering the draft. The site normally only serves published content, and it must not trust the admin's login cookie (different origin, different app).

The answer is a preview token: a short-lived signed token, created by the CMS API for one entry and one version, that lets the site fetch that draft and nothing else. Hosted CMSs give the site the same power in their own ways: Contentful through a separate Content Preview API with its own access token, Sanity through a drafts perspective on queries. On a Next.js site, the receiving end is Draft Mode: a route checks the secret, sets a cookie, and the page then skips its caches and fetches drafts.

Keep the token narrow: valid for one hour, read-only, scoped to one entry, and checked by the content API, not just by the site. A hosted preview key that can read every draft is far more powerful, so it lives only on the site's server, never in the browser. The preview response must send Cache-Control: private, no-store so a CDN never caches a draft for the public; Next.js Draft Mode sends a header like this for you.

In a side-by-side layout, the admin shows the preview in an iframe and after each save sends postMessage with the new version, so the preview refreshes without a full reload. Check event.origin on both sides.

Versions, compare, restore

The History panel lists versions newest first: who, when, and a summary such as "changed title, body, 2 tags". Picking two versions opens a compare view with a field-by-field diff (the audit chapter shows how). Restore never rewrites history: it copies the old content into a new draft version, which the editor reviews and publishes like any other change. That way restoring is itself undoable, and the log stays append-only.

Two editors, one entry

Ana opens the homepage entry at 10:00. Ben opens it at 10:02, swaps the hero image for the sale banner and saves at 10:05. Ana fixes a typo in the headline and saves at 10:07.

If her save sends the whole entry as she loaded it, the old hero image comes back and Ben's sale banner is gone. Nobody gets an error. This is the lost update problem, and in a CMS it's the bug that makes editors stop trusting the tool.

Sending only changed fields (a PATCH) shrinks the risk: Ana's save now only touches the headline. But it doesn't remove it. If both edit the headline, or Ben edits the body while Ana edits the summary that describes it, one of them still wins silently.

How the version check works

GET /api/entries/page/home returns the entry and the header ETag: "v42". The form keeps v42 as its baseline version, and saving sends PATCH with If-Match: "v42", which asks the server to apply the change only if the entry is still at that version.

The server compares and writes in one atomic step (UPDATE ... WHERE id = ? AND version = 42). If no row matched, it answers 412 Precondition Failed with the current version in the body. A save with no If-Match at all gets 428 Precondition Required (defined in RFC 6585 for exactly this lost-update case), so an old client or a script can't skip the check by accident.

Hosted CMSs build the same guard. Contentful's Content Management API, for example, takes the version in its own X-Contentful-Version header and answers 409 Conflict on a mismatch. Standard If-Match and 412 have the edge that generic HTTP clients and libraries already know them.

On a 412, the worst UI is "Someone else changed this entry. Reload?" because reloading throws Ana's typo fix away. The good UI is a three-way merge: the client has the base (v42, what Ana started from), mine (Ana's values) and theirs (v43, from the 412 body). Per field: if only one side changed it, take that side; if both changed it to different values, it's a real conflict, and only those fields need a decision.

type Pick = { field: string; value: unknown } | { field: string; conflict: [unknown, unknown] };

function merge3(base: Entry, mine: Entry, theirs: Entry, fields: string[]): Pick[] {
  return fields.map((f) => {
    const b = base.values[f], m = mine.values[f], t = theirs.values[f];
    if (equal(m, t)) return { field: f, value: m };
    if (equal(m, b)) return { field: f, value: t }; // only they changed it
    if (equal(t, b)) return { field: f, value: m }; // only I changed it
    return { field: f, conflict: [m, t] };          // both changed it
  });
}

In the homepage story: hero changed only by Ben, so take his; headline changed only by Ana, so take hers. Zero conflicts: the UI shows "Merged with Ben's changes from 10:05" and lets Ana save again with If-Match: "v43". Only when both touched the same field does she see a side-by-side choice for that one field. Rich text is one field here; merging inside a document is the job of the rich-text and google-docs designs, not ours.

Presence and soft locks

When a form opens, the client posts a heartbeat, PUT /api/presence/page/home, and repeats it every 15 seconds while the tab is visible (the Page Visibility API's visibilitychange event pauses it in hidden tabs). The server drops anyone silent for 45 seconds. Other open editors learn about it from a server-sent events stream or a poll every 15 seconds; the presence-and-cursors lesson compares the transports.

The header shows avatars, as Sanity Studio and the Contentful web app do for people in the same entry. If someone has unsaved changes, a banner adds: "Ana Ruiz is editing this entry (unsaved changes). Your changes may conflict." Ben can still edit. The lock is soft by design; the version check is what keeps the data safe.

The media library

Images and files are content too, but they behave differently: they're big, shared by many entries, and served through an image CDN. The media library is its own content type with a grid view, and every media field opens it as a picker. The upload itself (chunks, progress, retries, pausing) is the file-uploader guide; here we cover what a CMS adds.

Store one original, serve many sizes

Editors upload a 6000 by 4000 pixel, 9 MB photo. The site needs it at 400, 800 and 1600 pixels wide, as AVIF or WebP, cropped square for a card and 16 by 9 for a hero. The naive approach asks the editor to upload each version.

The better one stores only the original and lets an image service create variants on request from the URL: /img/abc123.jpg?w=800&fm=webp&fit=crop&ar=16:9. Imgix, Cloudinary, Sanity's image pipeline and Contentful's Images API all work this way, and the CDN caches each variant after its first request.

Automatic crops cut off heads. So the editor sets a focal point: a click on the most important spot, stored as two fractions, { x: 0.62, y: 0.30 }. Every crop is then centered as close to that point as the frame allows. The editor sees live previews of the main aspect ratios (1:1, 4:3, 16:9) next to the image while moving the point, which takes 5 seconds and saves an angry message from the design team.

Real products differ in how much they offer here. Sanity's image field stores a hotspot and a crop as fractions of the image, and its URL builder applies them. Contentful's Images API takes a named focus area instead (f=face, f=top, f=center), and an exact editor-chosen point comes from an add-on, such as the image focal point app Contentful publishes for its marketplace.

Alt text is required, and it lives in two places

WCAG success criterion 1.1.1 (Non-text Content, level A) asks for a text alternative for every meaningful image, and an empty alt="" for purely decorative ones so screen readers skip them. A CMS is the right place to enforce it, because the developer who writes the template never sees the image. The asset stores a default alt text, required on upload unless the editor ticks "decorative" (which outputs alt="").

A media field can override it per use, because the same photo of a store may mean "Our Berlin shop" in one article and "Queue on launch day" in another. The schema's altRequired: true makes publishing fail validation if neither is set; saving a draft still works. A saved view "Images missing alt text" turns the backlog into a task list.

Know where an asset is used before deleting it

Deleting an image that 14 published pages show leaves 14 broken images on the live site. The server keeps a reference index: when an entry is saved, it records which assets (and which other entries) it points to, including assets inside rich text. The asset's detail panel shows "Used in 14 entries" with links.

Delete is blocked while published entries use the asset. Instead the panel offers "Replace everywhere", which swaps the asset id in each entry as a new draft version, or Archive, which hides the asset from the picker without breaking anything.

Permissions in the UI, and who changed what

Our users have uneven powers. Staff editors publish anything, and admins also manage users. Agency freelancers create and edit articles but can't publish, and can't see the internalNotes field; translators edit only the localized fields of their own locale.

Permissions have three levels: per type (read, create, update, publish, delete on articles), per field (read or write internalNotes), and per entry (authors may update only entries they created). Strapi's admin roles have the same three: actions per content type, fields that can be unticked per action, and conditions such as "the administrator must be the creator".

The rule from the linkedin guide's privacy section applies unchanged: the server decides, the client only displays. If a freelancer can't read internalNotes, the API must leave the field out of every response, list, search result, version history and export. Hiding it in the form while it sits in the JSON is a leak anyone can read in the network tab. And every write is checked again on the server, field by field, so a crafted PATCH that includes internalNotes gets 403.

Where do the permissions come from? At sign-in the client loads a session payload with the user's roles compiled into simple lookups: can("article", "publish") and fieldAccess("article", "internalNotes"). Rules that depend on the entry ("own entries only") can't be compiled ahead, so each entry response carries its allowed actions: "_actions": ["update", "submit"].

The UI never recomputes those rules: it reads them. When an admin changes a role, the next request gets a 403; the client then reloads the session payload and re-renders.

Audit history with field-level diffs

"Who changed the price on this product?" is a daily question in a back office, and sometimes a legal one. The version log from the drafts chapter already stores every state. The audit log adds the events around it: who, when, what action (save, publish, unpublish, schedule, restore, delete, permission change), from which IP and client, and which fields changed. It is append-only and written by the server, never by the client.

The history panel turns two versions into a field-level diff. Short text fields show old and new side by side, while long text and rich text use a word-level diff inside the field, computed on the structured JSON so formatting changes show as "made bold" instead of a wall of markup. Relations show added and removed entries by their titles ("+ Pricing, - Promo"), looked up at display time. Fields the viewer can't read are left out of the diff too, or it would leak the value through history.

Localized content

The translation-architecture lesson is about translating the app's own UI strings ("Save", "Publish"). Content localization is a different problem: the articles themselves exist in 9 locales, and editors and translators work on them. A locale is a language plus an optional region, written as a BCP 47 tag such as de-AT (German as used in Austria).

The schema decides localization per field. title and body are localized: true, so they hold one value per locale. price, sku and author are shared: one value for all locales, because a product doesn't change its SKU in France.

The form gets a locale switcher in the header. Shared fields show in every locale, read-only for translators, with a small "shared" label so nobody is surprised that changing it in German also changes it in English. For translators, a side-by-side mode shows the source locale on the left, read-only, and their locale on the right.

Fallbacks

Austria uses German, so most de-AT content is the same as de, and requiring a copy for each locale creates thousands of duplicate values that drift apart. Instead each locale has a fallback chain, for example de-AT then de then en, the same idea the translation-architecture lesson uses for UI strings. An empty field takes the first value found along the chain; Contentful works this way, with each locale naming its fallback locale.

In our admin, the form shows the inherited value greyed out with "Inherited from de" and an "Override" button, so the editor sees what the site will render without the value being copied. Override only stores a de-AT value once the editor types something.

Translation status

Each localized field records which source version it was translated from. That gives three statuses per locale: missing (empty, maybe falling back), outdated (the source changed after the translation was made), and up to date. The list view shows a small badge row per entry ("fr: outdated, ja: missing") and a saved view "Outdated in my locale" becomes each translator's inbox. When the English body changes, the French one doesn't silently become wrong: it becomes visibly outdated.

Architecture, data model and API

With the hard parts decided, the architecture is mostly about boundaries: which piece knows about schemas, which knows about the network, and where plugins plug in. An admin app sits behind a login and has no SEO needs, so it's a client-rendered single-page app; the spa-vs-mpa lesson explains why that's the easy call here. One real decision remains: where schemas come from.

The parts and their boundaries

Follow the data for the main loop. An editor opens a list: the URL is parsed against the schema, turned into a query key, and the cache either answers or calls the API. Hovering a row prefetches that entry, so clicking opens the form from cache with no spinner, while a background refetch confirms the ETag.

Saving sends a PATCH with only the changed fields; the reply's new version becomes the form's baseline and replaces the entry in the cache, and the list queries for that type are marked stale so they refetch on next view.

Data model: where each kind of data lives

The client holds six kinds of data, and each has one home. Mixing them up is how admin apps end up with a stale list after a save, or a filter that a refresh forgets.

type FieldDef = {
  name: string;
  type: string;            // "string" | "relation" | "media" | ... | plugin types
  required?: boolean;
  localized?: boolean;
  access?: "read" | "write"; // already resolved for this user by the server
  [rule: string]: unknown;   // maxLength, to, many, options...
};
type ContentType = { name: string; label: string; titleField: string; fields: FieldDef[];
  list: { columns: string[]; defaultSort: string; paging: "offset" | "cursor" };
  form: { tabs: { label: string; fields: string[] }[] } };

type Entry = {
  id: string; type: string;
  version: number;            // also sent as the ETag
  publishedVersion: number | null;
  scheduledAt: string | null; // UTC instant
  values: Record<string, unknown>; // localized fields: { en: "...", de: "..." }
  updatedBy: { id: string; name: string }; updatedAt: string;
  _actions: ("update" | "publish" | "delete" | "submit")[];
};

The API

It's REST, because the shapes are generic (one set of endpoints for every type) and HTTP already has what we need: ETag, If-Match, 412, 202 for jobs. GraphQL works too (Contentful offers a GraphQL Content API next to REST, and Hygraph is built around GraphQL), but a generic admin gains little from per-query field selection when the schema already says which fields a screen needs.

GET    /api/schema                         -> ContentType[]   (ETag)
GET    /api/entries/:type?filter..&sort&limit&cursor -> { items, nextCursor, estimate }
GET    /api/entries/:type/:id?locale=de      -> Entry           (ETag: "v42")
POST   /api/entries/:type                    -> 201 Entry
PATCH  /api/entries/:type/:id   If-Match: "v42"  { values: {...changed} }
         -> 200 Entry (ETag "v43") | 412 { current: Entry } | 422 { errors } | 428
POST   /api/entries/:type/:id/publish  If-Match: "v43"  { at?: ISO instant }
GET    /api/entries/:type/:id/versions        -> Version[]
POST   /api/entries/:type/:id/preview-token   -> { url, expiresAt }
POST   /api/bulk  { action, type, ids? | filter? }  -> 202 { jobId }
GET    /api/bulk/:jobId                       -> { status, succeeded, failed[] }
PUT    /api/presence/:type/:id                -> 204   (heartbeat)
GET    /api/presence/stream                   -> text/event-stream

Errors share one shape, so the API client can map them without knowing the endpoint: { "code": "validation", "errors": [{ "path": "blocks.3.cta.url", "message": "Must be a full URL" }] }. Paths use the same dotted form as the form store, so mapping a server error to an input is a lookup, not a translation.

Performance, accessibility, and the plugin API

Performance: load what this type needs, before the click

Editors live in the app all day, so the metrics that matter are the speed of the next click and of typing, not the first load. Three techniques cover most of it.

• Split by field type and by custom view. As the code-splitting lesson shows, a route-level split isn't enough here: one generic form route can need a rich text editor, a map and a code editor, or none of them. Each field Input and each custom view is its own chunk. The shell stays under the 250 KB budget, and a 15-field FAQ form loads only small inputs.
• Prefetch on intent. When the pointer rests on a list row for about 100 ms (long enough to skip rows the mouse just crosses), the list prefetches that entry into the server cache and calls import() for the field chunks its type needs. The schema knows which those are. By the click, the form renders from memory, so an open that had a 1.5 second budget can take around 100 ms.
• Keep typing fast. Field-level subscriptions from the forms chapter keep Interaction to Next Paint (INP) low on a 120-field form; Google's good threshold is 200 ms, and a keystroke should stay far below it. Validate on blur, not on every key, and run the expensive cross-field rules only on save.

Lists show 50 rows by default, which needs no virtualization. If an editor picks 500 rows per page, the table switches to the virtualized mode from the data-table guide. Rendering cost is rarely the problem in a CMS; waiting on the network is, and prefetching is the fix.

Accessibility of complex forms

• Every generated input gets a real label, its help text and error joined through aria-describedby, and aria-invalid="true" when it fails. The field registry enforces this: the generic wrapper renders label, help and error, so plugins can't forget.
• Form tabs follow the WAI-ARIA tabs pattern (arrow keys between tabs, Tab into the panel). The error count from the forms chapter is part of each tab's accessible name, "Meta, 2 errors", and the error summary's links move focus to the field, switching tabs when needed.
• The relation picker is a WAI-ARIA combobox: role="combobox", aria-expanded, aria-controls, aria-activedescendant on the active option, arrow keys to move, Enter to pick, Escape to close. Picked items are a list, each with a button named "Remove tag Pricing". Reordering many relations offers Move up and Move down buttons, not only drag.
• Save results, bulk job progress and presence changes are announced in one aria-live="polite" region: "Saved at 10:42", "Ana Ruiz started editing".

Extensibility: dashboards and a plugin API

Teams will want more than custom fields: a dashboard widget showing "Articles scheduled this week", a custom view for orders, a toolbar action "Send to translation agency". A plugin is a bundle that registers any of these through one entry point, and gets a small, versioned API instead of the app's internals.

export default definePlugin({
  name: "stores",
  apiVersion: 2,
  fields: { geoPoint: { Cell: GeoCell, Input: lazy(() => import("./GeoInput")), validate } },
  views: { store: { detail: lazy(() => import("./StoreView")) } },
  widgets: [{ id: "low-stock", title: "Low stock", Component: lazy(() => import("./LowStock")) }],
  actions: [{ id: "geocode", label: "Geocode address", types: ["store"], run: geocode }],
});
// Inside plugins: useField(name), useEntry(), useApi(), usePermissions(). Nothing else.

Each plugin component renders inside its own error boundary and Suspense, so a crash shows "This field failed to load" with the raw value read-only, and the rest of the form still saves. Plugins written by our own teams run in the same page. Plugins from outside vendors are less trusted and can run in a sandboxed iframe that talks over postMessage, which is how Contentful's App Framework isolates apps.

The dashboard itself is just a grid of widgets, and the built-in ones are saved views rendered small: "My drafts", "Scheduled this week", "Images missing alt text".

Running it in the interview

An admin CMS question is wide, and the trap is spending 20 minutes on the table component. The interviewer wants to see that you find the few decisions that carry the design (schemas, saves, conflicts, drafts, permissions) and treat the rest as known patterns you can name and link.

Say the trade-offs out loud as you go: "I'm choosing explicit save over autosave because a half-done draft is visible in preview, and I'll protect against crashes with a local backup instead." A clear reason for a choice beats a long list of features.

Follow-up questions to expect