Headless

Headless of decoupled: must-have of hype?

Niels Aers

Bij Dropsolid krijgen we regelmatig de specifieke vraag voor een headless of decoupled website. Zo’n keuze heeft een enorme impact op een webproject. Aan de ene kant heeft het erg veel voordelen, toch is het niet voor elke situatie de beste oplossing. Het is daarom van groot belang om zeker zijn dat je om de juiste redenen voor headless kiest. Niet zeker of het een match is met jouw project? Onze experts denken altijd met je mee. Zo ben je zeker dat je op het juiste moment de correcte beslissing maakt.

In deze blog gaan we dieper in op het headless principe, kijken we naar enkele use cases en loodsen we je door een decision tree over headless CMS.

Wat is een headless of decoupled CMS?

1. Traditioneel

De traditionele CMS setup wordt ook wel ‘coupled’ genoemd. De content beheer omgeving (back-end) is hierbij direct verbonden aan de presentatielaag (front-end). Alle content en pagina’s worden aangemaakt in het Drupal-CMS. Via verschillende Drupal-templates, -paragrafen en -layout blokken worden ze aan bezoekers gepresenteerd.

De content bij een headless website is centraal opgeslagen in een content repository. Via een API wordt content aangemaakt, beheerd en uitgelezen. Een headless omgeving heeft verder geen enkele interesse of invloed op hoe en waar die content wordt gebruikt en gepresenteerd. Het levert puur content, meer niet. Met behulp van een Javascript framework zoals Angular of React wordt de presentatielaag in code specifiek per omgeving samengesteld en van de juiste context voorzien. De presentatie van content gebeurt dan via verschillende kanalen (website, app, in-store display) en technologieën.

Het praktische verschil met een coupled website? Content editors willen vaak invloed uitoefenen op de uiteindelijke presentatie van content. Terwijl dat in een traditioneel CMS gebeurt via de beheer omgeving, moet bij een headless CMS een developer worden ingeschakeld of moet aan elke presentatie laag een beheer omgeving worden gekoppeld.

Een voorbeeld van headless

Je openingsuren zitten éénmaal in de centrale content repository. Je hebt een mobiele app, meerdere websites en een interactieve in-store display die deze content tonen aan bezoekers. Pas je je openingsuren aan? Dan halen alle kanalen automatisch de nieuwe openingsuren op.

3. Fully decoupled static site

Bij een fully decoupled static site is de front-end volledig gebouwd in een framework. Ook de content zit hierin gebakken via HTML/CSS/JS files. Dit zorgt voor een zeer hoge performantie bij veel trafiek. Het nadeel is wel dat de volledige site opnieuw gecompileerd en gepubliceerd moet worden bij content aanpassingen. Vandaar het “statische” aspect.

Jamstack. Say what?

Jamstack staat voor Javascript, API en Markup. Het is een combinatie van een fully decoupled static site en een decoupled site. In essentie zijn het statische pagina’s met Javascript componenten die via een API handelen. Onze CTO deelde eerder zijn visie hierop.

4. Progressively decoupled

Progressively Decoupled, the holy grail? Het geeft je het beste van beide werelden. Je contentbeheer gebeurt via één centraal systeem. Afhankelijk van de specifieke noden kies je ervoor om bepaalde websites of ‘coupled’ bouwblokken voor de presentatielaag te vervangen door een decoupled versie. Dat gaat via één van de populaire Javascript frameworks waarbij de decoupled bouwblokken data ophalen via de API van het centraal systeem.

Het grote verschil met decoupled? Je beschikt naast een API om content uit te lezen ook over een presentatielaag en hoeft daarom niet alles zelf te bouwen. Je geniet dus eigenlijk van alle voordelen die headless te bieden heeft, zonder de nadelen erbij te nemen. 

Een ander groot voordeel van een progressively decoupled aanpak is dat deze gebaseerd is op de MACH architectuur. Niet vertrouwd met MACH? We leggen het hier uit

De hamvraag: wanneer kies je nu best voor welke oplossing? We leggen het uit aan de hand van onderstaande decision tree.

De voor- en nadelen van headless

Kiezen voor headless is een bewuste beslissing. We lijsten hieronder de voor- en nadelen even op.

Voordelen van headless Nadelen van headless
Ideaal voor zeer interactieve applicaties Zeer beperkte flexibiliteit voor content editors
Zeer performante front-end Duurder in ontwikkeling
Door de loskoppeling kan je enkel de presentatielaag vervangen en het CMS behouden Duurder in support
Centraal beheer van content waardoor al je platformen steeds de laatste en juiste informatie tonen Het project krijgt een grotere technische voetafdruk

Hoe maak je de juiste beslissing voor jouw website?

Headless is niet voor elke project dé way-to-go, dat is hopelijk al duidelijk. Hoe maak je dan wel een weloverwogen beslissing? Dries Buytaert, de founder van Drupal, maakte in 2019 een decision tree die verduidelijking biedt.

Dit is onze take-away:

Kies voor headless omdat... Kies niet voor headless omdat...
je bedrijf een duidelijke multi-channel visie heeft. je niet goed weet hoe Drupal best gebruikt wordt.
je bedrijf veel interactieve content aan zijn bezoekers biedt. het een hippe nieuwe technologie is.
er een duidelijke use case voor de meerwaarde van decoupled is. het toelaat om asynchroon te ontwikkelen, want dat kan ook anders.

 

De juiste manier?

  • Voorkom dat Drupal enkel een datastore wordt. Daar zijn andere oplossingen voor.
  • Maak ten volle gebruik van de editorial functionaliteiten van Drupal.
  • Security by design: verzeker dat je enkel de data ontsluit die nodig is voor de applicatie en die veilig is om prijs te geven.
  • Overweeg component-driven design. Je ontwerpt elk component los van de onderliggende technologie. Dat laat je sneller tot inzichten komen en stelt je later in staat om de juiste keuzes te maken en componenten onafhankelijk te schalen of te vervangen.

Als je ervan uitgaat dat progressively decoupled je default keuze is, dan kom je met een paar vragen tot de juiste keuze:

Decision tree headless

Het verdict: must-have of hype?

Headless of decoupled websites zijn geen hype. Het is een technologie die toelaat om steeds meer digitale kanalen en verschillende front-end frameworks flexibel met een centrale content repository te laten connecteren. Zorg dat je een weloverwogen keuze maakt bij de bouw van nieuwe digitale platformen. Denk goed na over de juiste motivatie, dat helpt je om de correcte keuzes te maken. Toch niet helemaal zeker waar je best voor kiest? Onze experten staan je graag bij in deze belangrijke keuze.

Populaire blogposts
Drupaljam 2020
Google introduceert 3 nieuwe SEO factoren in 2021 (Core Web Vitals)
Dit is Frederik Wouters, onze Enterprise Architect
Wat is MACH?
3 redenen om te investeren in je digital customer experience