De voor- en nadelen van een headless CMS (Drupal)

Drupal headless

Ons Atom-team heeft ervaring met het opzetten van grote geavanceerde headless omgevingen (gescheiden front- en backend). We gebruiken daarvoor het open source Drupal Content Management Systeem (CMS). Hoewel we in dit artikel steeds naar Drupal refereren is de informatie, de voor- en nadelen en overwegingen, gelijk voor alle headless CMS’en.

 

Headless CMS is flink in opkomst, je zou zelfs kunnen zeggen dat er sprake is van een ‘hype’. In veel gesprekken, voorafgaand aan een opdracht, wordt specifiek de vraag en wens voor een headless opzet van het Drupal CMS uitgesproken. We zien ook steeds vaker bureaus die in headless CMS een passende oplossing zien voor elk vraagstuk en geen CMS met traditionele opzet meer leveren.

 

Om als opdrachtgever het advies, wel of geen headless CMS, van een leverancier op waarde en waarheid te kunnen beoordelen is het goed om te weten wat headless betekent en wat de voor- en nadelen zijn.

Sparren over Headless CMS?

Benieuwd of de keuze voor een (Drupal)Headless CMS voor jouw organisatie de juiste keuze is? Laten we kennis maken. Wij zijn erg benieuwd naar jouw plannen en uitdagingen en denken graag vrijblijvend mee.

010 737 03 08
info@atom.nl

Wat is een headless CMS?

Er zijn drie manieren waarop je een Drupal website kan opzetten: traditioneel, headless en decoupled. De out-of-the-box ondersteuning van Drupal biedt ondersteuning voor alle drie deze architecturen. Dat is wat het Drupal CMS zo krachtig maakt.

Traditioneel: Standaard wordt Drupal, zoals afgelopen jaren gebruikelijk, opgezet als traditioneel CMS, ook wel coupled CMS genoemd. De content beheer omgeving (back-end) is direct verbonden/gekoppeld aan de presentatielaag (front-end). In deze opzet is Drupal zowel verantwoordelijk voor de back-end als front-end. Content wordt aangemaakt in Drupal en middels Drupal code en templates wordt die content aan bezoekers gepresenteerd.

Headless: Bij de opzet van het Drupal CMS als headless omgeving wordt back-end en front-end van elkaar gescheiden. De term ‘headless/API-only’ betekent dat de omgeving wordt opgezet als content repository en middels een API content kan worden aangemaakt, beheert en uitgelezen. Het heeft geen front-end, ook wel head genoemd. Drupal is bij een headless CMS opzet niet verantwoordelijk voor de presentatielaag (front-end).

Een headless CMS ontsluit content onafhankelijk van context, omgeving en kanaal. Het is een centrale opslag van content, waardoor er sprake is van een waarheid van content(single source of truth (SSOT). Dat wil zeggen dat er bijvoorbeeld 100 kanalen gebruikt kunnen maken van de openingstijden data, ontsloten door een headless CMS, waardoor overal en te allen tijde de juiste en laatste informatie wordt getoond. Een headless omgeving heeft verder geen enkele interesse of invloed op hoe en waar die content wordt gebruikt en gepresenteerd. Het levert content en meer niet. Met behulp van een Javascript framework zoals Angular of React wordt de presentatielaag (front-end) in code specifiek per omgeving samengesteld en van juiste context voorzien.

Redacteurs en marketeers willen vaak invloed uitoefenen op de uiteindelijke presentatie en positionering van content. Terwijl in een traditioneel CMS dit via een beheer, gekoppeld aan de front-end, gebeurt moet bij een headless CMS een developer worden ingeschakeld of moet aan elke presentatielaag een eigen beheer interface worden gekoppeld.

Decoupled: Drupal als decoupled CMS is al het ware een tussenvorm, het is een beetje van beide. Wanneer gesproken wordt over headless wordt vaak decoupled bedoeld, zeker in de combinatie met een CMS als Drupal. De keuze voor een content management systeem als Drupal wordt namelijk over het algemeen gemaakt om content te beheren. Minimaal wil je dus de presentatielaag behouden voor het beheren van content. In diverse situaties is het zelfs wenselijk om Drupal ook verantwoordelijk te maken voor de presentatielaag van de website en daarnaast je content via een API te ontsluiten naar andere kanalen.

Wanneer we spreken van een gedeelde ontkoppeling (scheiding front-end & back-end), waarbij we bijvoorbeeld content uit verschillende back-end systemen aggregeren maar door Drupal laten presenteren, noemen we dat progressively decoupled.

Binnen een decoupled Drupal omgeving wordt de content dus beheerd in het Drupal CMS, maar moet de presentatielaag (front end) content via door Drupal CMS beschikbaar gestelde API ophalen en presenteren aan de bezoeker. Dit is het grote verschil met headless: Je beschikt naast een API ook over een presentatielaag en hoeft daarom niet alles zelf te bouwen.

Drupal headless-first/API-first

Drupal is geen API-only, maar een API-first of headless first CMS. Drupal gaat in de architectuur en ontwikkeling eerst uit van een volledige werking met API, maar levert out-of-the-box een ook een traditionele (coupled) presentatielaag. Op die manier kan er gekozen worden voor een gekoppelde front-end, met extra mogelijkheden voor redactionele gebruikers, of voor het zelf bouwen van een maatwerk presentatielaag met een Javascript framework als Angular of React.

Dit is wat Drupal ook zo krachtig maakt, de keuze om een omgeving traditioneel, headless en decoupled op te zetten. Kies je nu voor Drupal in traditionele opzet, dan wordt de optie voor headless of decoupled niet uitgesloten en kunnen in een later stadium, wanneer de business daar om vraagt, andere kanalen van content worden voorzien via de Drupal API. Drupal limiteert je niet tot een gekoppelde (coupled/traditioneel) aanpak, maar ook niet tot een ontkoppelde (headless/decoupled).

 

 

Voor- en nadelen headless & decoupled

Headless en decoupled lijken erg op elkaar. In veel situaties wordt headless als benaming gebruikt daar waar decoupled bedoeld wordt.

In feite is headless niets nieuws, het is simpelweg een content repository/opslag, waarmee het mogelijk is content te publiceren naar meerdere kanalen. Dat geldt zowel voor web als non-web (IoT, apps, wearables, VR, narrowcasting etc), waarbij die kanalen verantwoordelijk zijn voor de weergave van die content. Een decoupled opzet van Drupal voegt daar een presentatielaag aan toe voor minimaal het beheer.

De populariteit van headless neemt toe, doordat gebruikers steeds vaker content consumeren op verschillende apparaten en kanalen. Veel partijen willen die gebruikers overal kunnen bereiken en voorzien van content. Met headless Drupal CMS is dat mogelijk.

Voordelen van headless of decoupled Drupal CMS:

  • Content centraal opgeslagen en middels de Drupal API eenvoudig beschikbaar te stellen aan verschillende omgevingen/kanalen.
  • Content centraal beheerd, waardoor consumerende platformen altijd de laatste en juiste informatie ter beschikking hebben en tonen.
  • Voor elke omgeving en kanaal kan desgewenst een specifieke technologie en leverancier gekozen worden, waardoor afhankelijkheden afnemen en voor specialisatie gekozen kan worden.
  • Geen templates of thema waarbinnen gewerkt moet worden, waardoor er volledige vrijheid en flexibiliteit is om een unieke, op de omgeving, doelgroep en gebruiker afgestemde gebruikservaring te creëren.
  • Meer flexibiliteit voor het AB testen van een front-end.
  • Front-end en back-end ontwikkelaars kunnen onafhankelijk van elkaar werken, hierdoor kan sneller worden ontwikkeld.
  • Mogelijkheid om content naadloos samen te brengen en te presenteren vanuit verschillende back-end omgevingen, naast de content uit Drupal.
  • Mogelijkheid tot integreren van niet CMS en niet Drupal componenten, zoals microservices en functionaliteit van derde.
  • Back-end en front-end zijn gescheiden. Verantwoordelijkheden zijn verdeeld en daardoor is het makkelijker om losse onderdelen te schalen.
  • Door het renderen van de presentatielaag(front-end) niet de verantwoordelijkheid van de server en Drupal te maken, maar van Javascript en de browser(client side), kan een website veel sneller laden.
  • Een headless CMS wordt vaak als veiliger gezien mits juist geconfigureerd, omdat de presentatielaag(front-end) geen directe koppeling heeft met de back-end en database, maar communiceert via de API elk met een specifieke taak en beperkte output.
  • Tussen front- en back-end wordt vaak een hoogwaardige Content Delivery Netwerk geplaatst, wat het risico op een denial, of service door een DDOS aanval, verlaagd.

Nadelen van headless of decoupled Drupal CMS:

  • Bij een headless CMS wordt de content, met behulp van een Javascript framework als React en Angular, uit het headless Drupal CMS opgehaald via API en getoond. Het tonen via een Javascript framework maakt indexatie door Google en andere zoekmachines, zonder hier extra tijd en aandacht aan te besteden, lastig dan wel onmogelijk.
  • Voor elk kanaal moet een presentatielaag (front-end) gebouwd, beheert en onderhouden worden. Standaard functionaliteit voor traditionele CMS omgevingen moeten nu zelf ontwikkeld worden. Een fout in de code moet zelf worden opgelost, waar dat anders voor plugins/modules door de community zou gebeuren. 
  • Het IT landschap en de architectuur kan snel in complexiteit toenemen wanneer meerdere back-end en frontend systemen met elkaar moeten communiceren en wellicht ook door meerdere ontwikkelaars/leveranciers worden ontwikkeld en beheerd. Afhankelijkheden tussen systemen en het totale overzicht van de architectuur kan verloren gaan.
  • Voor het invloed uitoefenen op de presentatie en positionering van content op een kanaal is een developer nodig. Functionaliteit als inline editing en pre-publish content previews zijn niet beschikbaar.
  • De vrijheid in de keuze voor de technologie van de presentatielaag per kanaal, brengt het risico met zich mee dat combinaties aan technologie in een vendor-lock kunnen resulteren. Daarnaast kan de samenwerking tussen leveranciers en technologie het geheel minder beheersbaar maken.
  • De vrijheid in keuze voor een technologie en leverancier per kanaal kan flink invloed hebben op de kwaliteit van omgevingen. 
  • Door een scheiding van de lagen ontstaan er meerdere lagen die onafhankelijk van elkaar, maar ook met elkaar moeten worden getest wat het proces intensiever maakt.
  • Bij een coupled Drupal CMS wordt content daar beheerd en beveiligd. Bij een headless CMS moet je zelf meer nadenken over de beveiliging, niet iedereen mag zomaar content inschieten. Ook validatie van content wordt door een coupled Drupal CMS meer uit handen genomen dan een headless opzet.

 

Voor en nadelen van headless

Samengevat: Vraagstuk is bepalend

Als klantgericht internetbureau en specialist/adviseur binnen het vakgebied is het onze taak de opdrachtgever te helpen in de keuze voor een oplossing die past bij het vraagstuk, de roadmap en het budget. Dat (Drupal)leveranciers het headless CMS standaard als oplossing kiezen voor elk vraagstuk, is wat ons betreft absoluut verkeerd.

De technische benodigdheden voor een project zijn in de keuze voor een coupled, headless of (progressively) decoupled CMS oplossing bepalend. Zoals Drupal geen ‘one solution fits all’ oplossing is, gaat dat ook op voor headless en Drupal headless.

Headless voor jouw project?

Overweeg jij momenteel de keuze voor een headless CMS of decoupled CMS, maar heb je hulp nodig of wil je sparren over het toepassen van de genoemde overwegingen? Wij denken altijd graag vrijblijvend mee! Plan een vrijblijvende digitale kennismaking of neem contact op!

Headless samengevat