Schemaontwerp voor Headless CMS op Schaal

Je startte met 10 contenttypes en alles voelde overzichtelijk. Een jaar later heb je 40 types, waarvan er een aantal ruwweg hetzelfde doen, en je GraphQL-queries zijn drie niveaus diep. Geen enkele beslissing maakte het schema rommelig — het waren honderd kleine beslissingen zonder een kader. Zo ziet dat kader eruit.

Scheid Structuur van Presentatie

Een CallToAction-type moet een kop, een ondersteuningsregel en een knoplabel opslaan. Het moet geen achtergrondkleur, opvulwaarde of layoutvariant opslaan. Presentatie hoort thuis in je Next.js- of Nuxt-component, niet in het CMS. Als je de twee door elkaar haalt, eindig je met tientallen bijna-identieke types — BlauweCta, DonkereCtaHero — die je editors niet kunnen onderscheiden en je ontwikkelaars haten om te onderhouden.

Gebruik Referenties, Geen Duplicatie

Als vijf paginatypes allemaal een auteursbio weergeven, sla de auteur dan één keer op in een Author-type en verwijs er overal naar. Hetzelfde geldt voor productfeatures, prijsniveaus en teamleden. Duplicatie voelt in het begin sneller; op schaal levert het pijnlijke inconsistenties op wanneer iemand een bio op één plek bijwerkt maar niet op de andere vier.

• Verwijs naar gedeelde entiteiten: auteurs, categorieën, tags, productspecificaties
• Embed data die echt bij één entry hoort: de introparagraaf van een pagina, de publicatiedatum van een blogpost
• Gebruik many-to-many-referenties voor collecties: een post die tot meerdere categorieën behoort

Ontwerp voor de Query, Niet het Formulier

Denk na over wat je TypeScript SDK gaat opvragen voordat je een veld definitief maakt. Als je homepage posttitel, auteursnaam en categorieslug in één response nodig heeft, modelleer die dan als velden op het hoogste niveau van gelinkte types — niet genest in rich-text of JSON-blobs. Een veld dat is begraven in een ongestructureerde blob kan niet worden opgevraagd, gefilterd of gesorteerd. Een correct veld wel.

ContentGrid's schema-editor toont je de API-vorm terwijl je types bouwt, wat het makkelijker maakt problemen te ontdekken voordat ze worden vastgelegd. Controleer of de responsevorm overeenkomt met wat je frontend nodig heeft, niet alleen hoe het formulier eruitziet in de editor.

Plan voor Veroudering

Op schaal zul je oude velden en types moeten uitfaseren. Houd daar van meet af aan rekening mee. Geef velden duidelijke en consistente namen — heroHeading niet h1, publishedAt niet date. Consistente namen maken het makkelijker codemods te schrijven als je toch moet migreren. Houd een korte interne notitie bij met types, waarvoor ze dienen en wanneer ze zijn toegevoegd. Dit loont wanneer je een nieuwe ontwikkelaar inwerkt die wil begrijpen waarom LegacyArticlePage nog bestaat.

Schemaschulden stapelen zich langzaam op en dan opeens snel. De teams die dit vermijden, behandelen hun contentmodel als een geversioneerd, beoordeeld artefact — niet als iets dat één ontwikkelaar op een middag inricht en nooit meer aanraakt.