Wanneer headless architectuur de moeite waard is

Headless loont als je dezelfde content of commerce-functies aan meer dan één frontend levert, of als je frontend dingen moet doen die een standaardplatform niet kan. Je hebt dan wel een team nodig dat die frontend blijft onderhouden. Voor één marketingsite of een webshop die prima draait op een standaardthema, betaal je vooral voor extra onderdelen.

Wat je precies loskoppelt

Bij headless haal je de frontend los van het CMS of het commerceplatform. Shopify omschrijft headless commerce als een storefront waarvan de frontend los staat van de backend. De backend levert data via API's, en de frontend is een eigen applicatie die jij bouwt, host en bewaakt.

Dat laatste is de grootste verandering. Preview, redirects en caching deed het platform voor je, en die regel je nu zelf.

Wanneer het loont

Ik zie vier situaties waarin headless de extra moeite waard is:

• Je levert dezelfde content of catalogus aan meerdere kanalen, zoals een website, een app, schermen in de winkel of een portaal voor partners.
• Je combineert op één pagina data uit verschillende systemen: productdata uit een PIM, content uit een CMS en prijzen of voorraad uit een ERP.
• Je frontend heeft eisen die een thema niet haalt, zoals een productconfigurator, zware personalisatie of strakke eisen aan laadtijd.
• Je wilt de backend later vervangen zonder dat de klant iets merkt. Met een eigen frontend kun je achter de schermen van platform wisselen.

Wanneer het je vooral geld kost

Heb je één site, een klein marketingteam en een standaardthema dat het werk doet, dan raad ik het af. Je bouwt dan een tweede applicatie die hetzelfde doet als de eerste.

Hetzelfde geldt als er na de lancering geen frontend-team overblijft. Een headless frontend heeft framework-upgrades, dependency-updates en beveiligingspatches nodig. Doet niemand dat, dan veroudert de site sneller dan een thema dat de leverancier bijhoudt.

Let ook op je redacteuren. Wie gewend is aan een paginabouwer in het platform, verliest die bij headless, tenzij je CMS een goede visuele editor heeft. In een headless CMS kiezen schrijft Bas over die keuze.

De extra onderdelen die je zelf bouwt

Preview is het eerste dat redacteuren missen: ze willen een concept zien voordat het live staat. In Next.js gebruik je daarvoor Draft Mode. Het CMS opent een preview-URL met een geheim token, en Next.js slaat voor die redacteur de cache over, terwijl andere bezoekers de gecachete versie blijven zien. Dat werkt goed, maar jij bouwt en beveiligt het.

Verder komt dit op je bord:

• Cache-invalidatie, met webhooks vanuit het CMS en het commerceplatform als content of prijzen veranderen.
• Redirects, sitemaps, canonical-URL's en structured data. Het platform deed dat, nu is het jouw code.
• Klantaccounts en inloggen. Bij Shopify loopt dat via een aparte Customer Account API.
• De overgang naar de checkout. De Storefront API van Shopify levert producten, collecties, zoekresultaten en de winkelwagen, en stuurt de klant daarna door naar de checkout.
• Monitoring en foutafhandeling over meerdere leveranciers heen. Valt de zoekdienst uit, dan moeten je productpagina's blijven werken.

Composable commerce betekent meer leveranciers en contracten

Ga je verder dan een losse frontend, dan kies je per onderdeel een leverancier: commerce, CMS, zoeken, PIM. Je kunt dan per onderdeel de beste kiezen, maar elk onderdeel brengt ook een eigen contract, prijsmodel, SLA en roadmap mee.

Maak daarom vooraf een paar afspraken. Wie beheert de integratielaag tussen frontend en leveranciers? Wie belt welke leverancier als er 's nachts iets stuk is? En hoe leg je de contracten tussen je eigen onderdelen vast? Boris schreef over dat laatste in API-first ontwerpen.

Ik zou de frontend nooit rechtstreeks met vijf leveranciers laten praten. Zet er een eigen laag tussen, een backend-for-frontend, die de API's van leveranciers vertaalt naar wat jouw pagina's nodig hebben. Wissel je een leverancier, dan pas je die laag aan en blijft de frontend staan.

Wie het beheert

Een headless frontend vraagt onderhoud zolang hij live is. Reken op blijvende capaciteit, ook als er geen nieuwe features komen. Bij een kleine site is dat een deel van de tijd van één developer. Bij composable commerce met meerdere leveranciers is het een team.

Bij het opdelen van je backend speelt dezelfde afweging: meer losse onderdelen betekent meer grenzen om te bewaken. Daarover gaat monoliet of microservices.

Een tussenvorm

Je hoeft niet alles tegelijk om te bouwen. Een tussenvorm die ik aanraad, is dat checkout en klantaccount op het platform blijven en je alleen de content- en landingspagina's headless bouwt. Daar willen teams meestal de meeste vrijheid, en daar is het risico het kleinst.

Werk je met Shopify, dan is er een eigen headless route. Hydrogen is de toolkit van Shopify om een storefront te bouwen en Oxygen is de hosting voor die storefronts. Je zit dan nog steeds in het ecosysteem van Shopify, maar de frontend is van jou.

Bronnen

• Shopify: headless storefronts
• Next.js: Draft Mode