Skip to content
AITroveRead. Build. Understand.
Make this comfortable

CMS Public Projections and Route Identity

Last updated: 5 Oct 20268 min read
tutorial
IntermediateBy AITrove Editorial

A content management system stores editorial state; a public site serves an admitted projection of that state. The public reader should accept published records only, select a small set of known fields, and convert the CMS record into a site-owned route model. A post ID, slug, status, content revision, and canonical path solve different problems. IDs survive title edits; slugs may be renamed; status controls admission; revisions identify exact content; canonical paths direct users to the chosen public address. Do not hand the entire editorial record to the browser because private notes, draft bodies, custom metadata, or future fields can appear without a frontend change. A read-time filter is still needed even if a CMS query parameter asks for published posts, because the route that returns one record must obey the same rule.

Working case

AI Trove stores an article with ID 447, the slug browser-cache-ownership, a published revision 8, and a draft revision 9 containing an unfinished security note. The public site must keep rendering revision 8 until the editor publishes the next revision. If the frontend fetches the latest record by slug and trusts a local flag, a draft response can reach the page or a search index. If the editor later renames the slug, bookmarks at the former path should receive a deliberate redirect to the one canonical path. An unrelated article must not steal the old slug, and a deleted article must not leave a successful empty page. A route table keyed only by title is insufficient because titles need not be unique and can change for editorial reasons.

Implementation boundary

javascript
function publicArticle(record) {
  if (record.status !== "publish") return null;
  const canonicalPath = `/web-tech/${record.slug}`;
  return Object.freeze({
    id: record.id,
    canonicalPath,
    revision: record.publishedRevision,
    title: record.title,
    summary: record.summary
  });
}

const editorialRecord = {
  id: 447, slug: "browser-cache-ownership", status: "publish",
  publishedRevision: 8, title: "Browser Cache Ownership",
  summary: "Assign each response a cache owner.", privateNote: "Draft review"
};
console.log(publicArticle(editorialRecord));

Define a public content object whose constructor requires published status and exact fields: stable ID, canonical path, title, summary, approved HTML, revision, and updated time. Keep editorial fields outside this type. Normalize the canonical path once; reject duplicate routes during build or ingestion. Maintain a redirect mapping for changed paths, with a bounded chain and a terminal response for removed content. Sanitize or otherwise constrain approved HTML at the trust boundary rather than assuming every editor role is safe. Treat nested media references and related-lesson routes as dependencies: an article should not link to a route the public reader cannot serve. Return a deliberate 404 for a draft or nonexistent path; reserve a server error for a failed CMS read so monitoring does not mistake an outage for missing content.

Cost and boundaries

Fetching only required fields reduces response bytes and client parse work. In a build or warm-up over N records, constructing the route map takes O(N) expected time and O(N) memory with a hash map; collision checks are part of this pass. A direct map lookup is expected O(1), while a remote CMS request adds network latency and must have a deadline. Draft exclusion is a correctness boundary, not a cache optimization. A redirect table adds storage proportional to renamed paths and can accumulate indefinitely without a retirement policy. Separate the public model from editor permissions so the cache can hold published responses without storing hidden fields. Measure response width, missing-path rate, redirect chains, and stale revision age.

Failure trace

Publish revision 8, save an unpublished revision 9, and request the article through the public route, search document builder, and related-card builder. Each must still use revision 8. Force the CMS API to return a private metadata field and verify the public projection drops it. Create two records with the same canonical path and make ingestion fail rather than choose whichever arrives last. Rename a slug twice and verify the oldest address resolves to one canonical destination without a loop. Unpublish a previously public page and make the public route and navigation list withdraw it. Finally, interrupt the CMS request and confirm the failure is logged as an upstream outage rather than silently converted to a 404.

Verification

  • Draft revisions never enter public cards or search documents.
  • Duplicate canonical paths fail validation before serving.
  • Private CMS fields are absent from the response object.

Practice drill

Build a small route materializer for three article records: one published, one draft, and one renamed. Accept only the published record into the route map and expose only the public fields. Keep a separate old-path redirect map with loop rejection. Feed the result to a page renderer and a search-index builder, then compare their admitted IDs and revisions. Add a second record with a conflicting path and require a hard validation error. Repeat with malformed HTML and an unresolved related route. Record which errors block publication and which can be reported for editorial repair without hiding a valid older revision.

Decision note

The CMS owns editorial state; the public site owns a narrow, versioned route model and rejects any unapproved revision.

Common Mistakes

  • Using a slug as a stable record identity.
  • Passing the entire CMS object into a public component.
  • Turning upstream read failures into missing-page responses.

Related lessons

CMS Content, Publication, and Preview Boundaries; CMS Draft Preview Authorization and Cache Isolation; CMS Media Variants, Alt Text, and Asset Ownership; CMS Publish Events, Cache, Search, and Rollback; Content Discovery and Structure; Server Rendering and Client Data Flow; API Contract Evolution and Client Migration.

Apply and check

Build Project: CMS Publication Reconciliation and review Web Development: CMS publication contracts.

web-tech
web-development
Storage details