Headless applicatie: wat het is, wanneer het werkt en wanneer niet

Een headless applicatie is een toepassing waarbij de achterkant en de voorkant volledig van elkaar zijn losgekoppeld. De achterkant beheert de gegevens en stelt die beschikbaar via een API, en de voorkant haalt die gegevens op en bepaalt zelf hoe ze eruitzien. Het woord headless slaat op die ontbrekende voorkant: de “head” is de presentatielaag, en die zit er in dit model niet standaard aan vast. Dat klinkt als een detail voor ontwikkelaars, maar het bepaalt in de praktijk hoe snel je kunt schakelen, wat het kost en hoeveel beheer je eraan hebt.

In het kort

• Een headless applicatie scheidt de gegevenslaag van de presentatielaag, die met elkaar communiceren via een API.
• Het grootste voordeel is dat één bron meerdere kanalen kan bedienen: website, app, kassasysteem en scherm in de winkel.
• Het grootste nadeel is complexiteit: je beheert twee systemen in plaats van één, en eenvoudige wijzigingen vragen vaker een ontwikkelaar.
• Voor een gewone bedrijfswebsite is headless meestal overkill, terwijl het bij meerdere kanalen of hoge bezoekersaantallen juist zijn geld opbrengt.

Hoe een headless applicatie werkt

Om te begrijpen wat er anders is, helpt het om eerst naar het klassieke model te kijken. In een traditionele opzet zit alles in één systeem: de database, de logica die bepaalt wat er gebeurt, en de sjablonen die de pagina’s opbouwen. Vraagt een bezoeker een pagina op, dan haalt het systeem de gegevens op, plakt die in een sjabloon en stuurt kant-en-klare HTML terug naar de browser. Voorkant en achterkant zijn onlosmakelijk verbonden.

Bij een headless applicatie is die keten doorgeknipt. De achterkant doet nog steeds het werk met gegevens, maar levert geen opgemaakte pagina’s meer. In plaats daarvan stelt hij die gegevens beschikbaar via een API, meestal in de vorm van JSON. Wat er vervolgens mee gebeurt, is aan de voorkant.

De volgorde ziet er dan zo uit:

• De gegevenslaag: een database of contentsysteem waarin de informatie wordt beheerd en bijgewerkt
• De API: de tussenlaag die die gegevens op verzoek uitlevert, via REST of GraphQL, met authenticatie voor wie wat mag opvragen
• De voorkant: een los gebouwde toepassing die de gegevens ophaalt en presenteert, bijvoorbeeld gemaakt met React, Vue of Svelte
• De uitlevering: die voorkant staat vaak op een contentnetwerk verspreid over de wereld, zodat pagina’s dicht bij de bezoeker vandaan komen

Het interessante gevolg is dat er meerdere voorkanten op dezelfde achterkant kunnen zitten. Dezelfde productinformatie voedt dan de webshop, de mobiele app, het scherm in de winkel en de catalogus die een partner in zijn eigen systeem toont. Je onderhoudt de informatie één keer en publiceert hem overal, in plaats van dat elk kanaal zijn eigen kopie bijhoudt die na een half jaar afwijkt.

Er is nog een variant die je tegenkomt: composable of MACH-architectuur. Dat is dezelfde gedachte doorgetrokken naar het hele landschap, waarbij je per onderdeel de beste dienst kiest en die via API’s aan elkaar knoopt. Een headless applicatie is daar dan één bouwsteen van.

Voordelen headless webapplicaties

De voordelen van headless webapplicaties komen bijna allemaal voort uit diezelfde scheiding. Omdat de onderdelen los van elkaar staan, kun je ze ook los van elkaar aanpassen, vervangen en opschalen.

• Schaalbaarheid: de voorkant en de achterkant schalen apart. Bij een piek in bezoekers schaal je alleen de laag die de druk krijgt, en een voorkant die als statische bestanden op een contentnetwerk staat verwerkt een piek zonder dat de database er iets van merkt
• Snelheid: pagina’s kunnen vooraf worden opgebouwd en vanaf een server dicht bij de bezoeker worden geleverd, wat de laadtijd flink drukt
• Meerdere kanalen uit één bron: website, app, kassasysteem en partnerintegratie halen dezelfde gegevens op, dus je hoeft niets dubbel bij te houden
• Vrije technologiekeuze: de voorkant is niet gebonden aan de taal of het framework van de achterkant, en je kunt hem vervangen zonder de achterkant aan te raken
• Parallel werken: front-end- en back-endteams zitten elkaar niet in de weg, zolang ze het over de API eens zijn
• Kleiner aanvalsoppervlak: het beheergedeelte staat niet op hetzelfde openbare adres als de website. Wat niet publiek bereikbaar is, kan ook niet vanaf het open internet worden aangevallen
• Toekomstvast: komt er een nieuw kanaal bij, dan bouw je daar een voorkant voor in plaats van het hele systeem opnieuw op te zetten

Dat laatste beveiligingspunt verdient nuance, want het is een verschuiving en geen oplossing. Je vermindert de kans dat iemand via de openbare website bij het beheer komt, maar je introduceert een API die zelf goed beveiligd moet worden. Doe je dat slecht, dan heb je het probleem alleen verplaatst naar een plek waar minder mensen kijken.

Nadelen headless webapplicaties

Tegenover die voordelen staan reële kosten, en die worden in verkoopgesprekken zelden even uitgebreid behandeld. De nadelen van headless webapplicaties zijn vooral organisatorisch en financieel, niet technisch.

• Meer bewegende delen: je beheert twee systemen, een API ertussen en vaak twee hostingomgevingen. Elk onderdeel kan stuk, en bij een storing is de vraag “waar zit het” ineens een onderzoek
• Hogere bouwkosten: wat in een klassiek systeem met een sjabloon en een plug-in geregeld is, moet je hier zelf bouwen. Reken op een aanzienlijk hoger startbudget
• Afhankelijk van ontwikkelaars: een redacteur kan tekst en beeld aanpassen, maar een nieuw soort pagina of een extra veld op een andere plek vraagt vrijwel altijd om een ontwikkelaar
• Voorbeeldweergave werkt niet vanzelf: bekijken hoe iets eruitziet voordat je publiceert, is in een headless applicatie iets dat apart moet worden gebouwd
• Vindbaarheid vraagt aandacht: een voorkant die pas in de browser wordt opgebouwd, is voor sommige crawlers leeg. Je moet pagina’s dus vooraf opbouwen of op de server laten renderen, en dat is extra werk
• Kennisafhankelijkheid: er zijn minder mensen die dit kunnen onderhouden dan er WordPress-bouwers zijn, wat betekent dat je duurder uit bent en minder makkelijk wisselt

Er komt een praktisch nadeel bij dat pas na een jaar zichtbaar wordt. Een klassiek systeem heeft een ecosysteem waarin veel al bestaat: een formulier, een zoekfunctie, een cookiemelding. In een headless applicatie bouw je die zelf, en daarmee wordt jouw team ook verantwoordelijk voor het onderhoud en de beveiliging ervan.

Headless websites

Bij websites is headless de afgelopen jaren het snelst opgekomen, en dat gaat vrijwel altijd over hetzelfde patroon: een bestaand contentsysteem als achterkant, met een moderne voorkant erop. WordPress is daarbij verreweg de meest gebruikte achterkant, en niet zonder reden.

WordPress heeft een ingebouwde REST API, en met een uitbreiding kun je de gegevens ook via GraphQL opvragen. Daarmee blijft de redactie in de vertrouwde beheeromgeving werken, terwijl de bezoeker een voorkant ziet die met bijvoorbeeld Next.js of Nuxt is gebouwd. Voor uitgevers en grotere sites is dat aantrekkelijk: je houdt een systeem dat iedereen kent en wint aan snelheid en flexibiliteit.

Wat je daarbij inlevert, is precies waar WordPress zijn populariteit aan dankt. Thema’s werken niet meer, want die bepalen de voorkant en die is er niet. Een groot deel van de plug-ins valt af, omdat veel plug-ins hun werk doen door HTML aan de voorkant toe te voegen. Denk aan formulieren, pop-ups, cookiemeldingen en de meeste SEO-functionaliteit: dat moet je in een headless opzet opnieuw regelen. Ook de knop “voorbeeld bekijken” werkt niet zonder extra bouwwerk, wat redacteuren als eerste opvalt en waar ze het langst over blijven klagen.

Voor de meeste bedrijfswebsites is de conclusie dan ook nuchter: klassieke WordPress voldoet prima. Een site met vijftig pagina’s, een contactformulier en een blog wordt van een headless opzet duurder en niet beter. Het wordt pas interessant als je echt tegen grenzen aanloopt, bijvoorbeeld bij hoge bezoekersaantallen, bij een site die dezelfde content ook aan een app moet leveren, of bij een organisatie met meerdere merken en landen die uit één contentbron gevoed worden.

Naast WordPress zie je systemen die vanaf het begin als headless zijn opgezet, zoals Strapi, Contentful, Sanity en Storyblok. Die hebben geen presentatielaag en dus ook geen erfenis van thema’s en plug-ins. Bouw je nieuw en weet je zeker dat je headless wilt, dan is zo’n systeem doorgaans een logischer vertrekpunt dan WordPress achteraf omvormen.

Wanneer een headless applicatie de moeite waard is

De vraag is niet of headless beter is, maar of jouw situatie de extra complexiteit rechtvaardigt. Een paar signalen die daarop wijzen: je onderhoudt dezelfde informatie op meer dan één plek, je hebt naast een website ook een app of ander kanaal dat dezelfde gegevens toont, je site loopt tegen prestatiegrenzen aan die met caching niet meer op te lossen zijn, of je hebt eigen ontwikkelaars in dienst die dit kunnen onderhouden.

Herken je daar niets van, dan is de eerlijke conclusie dat je het geld beter elders besteedt. Een headless applicatie lost problemen op die je moet hebben voordat de oplossing iets waard is. Kies je er wel voor, begin dan bij het contract en niet bij de techniek: leg vast wie eigenaar is van de code, hoe de API is gedocumenteerd en wat er nodig is om over te stappen naar een andere partij. Juist bij een opzet met veel losse onderdelen is dat het verschil tussen flexibiliteit en een duur bouwwerk dat maar één partij nog begrijpt.