We krijgen deze vraag vaak. Moeten we onze website headless opbouwen? Een slecht idee is het niet. Het uitgangspunt is zelfs fantastisch: de bezoeker laadt een website slechts één keer in de browser en vanaf dan kan hij genieten van enorm vloeiende gebruikerservaring. Dat is zeker mogelijk, door Drupal te koppelen aan een frontend applicatie gebouwd in Angular.js of React.js bijvoorbeeld. Drupal is immers API-first opgebouwd. 

Maar is het een goed idee om je Drupal website headless op te bouwen?

Het antwoord is, zoals vaak, genuanceerd en sterk afhankelijk van wat je wil bereiken. Je moet de voordelen en nadelen tegenover elkaar afwegen. Laat ons eerst even bekijken wat een headless CMS is, en wat deze voor -en nadelen zijn. 

Traditional vs decoupled

Wat is een headless CMS?

Een headless CMS (of ook Decoupled CMS) is een Content Management Systeem dat enkel dient om data in te bewaren, te bewerken en op te halen. De effectieve presentatie van deze data op een website of een ander medium wordt door een andere applicatie gedaan. 

Terwijl Drupal in zijn conventionele vorm ook dient als presentatielaag, hoeft dat niet zo te zijn. Drupal is prima inzetbaar als centrale data store voor verschillende frontend applicaties. Denk aan websites, webapps, mobile apps... enzovoort. Je kan beide ook combineren. Je kan Drupal nog steeds gebruiken als website medium en toch ook de data aanbieden aan een externe applicatie, een mobile app bijvoorbeeld. Het ene sluit het andere niet uit.

Voordelen van een headless CMS

Het voornaamste voordeel zit 'm in vrijheid van keuze. Door de "backend" van de "frontend" te koppelen, kan je Drupal gebruiken als CMS, en eender welke andere applicatie als visualisatielaag. Door de sterke opkomst van zeer performante Javascript frameworks van het laatste decennium, zet dat de deur open voor enorm snelle, gebruiksvriendelijke frontend applicaties

De kenmerken van zo'n applicaties zijn vaak dat, eens de pagina geladen is, geen nieuwe page loads meer nodig zijn. De webapp gedraagt zich zoals een mobile applicatie: snel, vloeiend en gebruiksvriendelijk. Dat is ook logisch, want deze frontend user experience wordt op maat gemaakt. 

Nadelen van een headless CMS

En in dat laatste zit meteen het eerste nadeel. Doordat het op maat gemaakt is, is het ook duurder. Het vergt immers meer ontwikkeltijd om zo'n aparte frontend app te maken. Je hebt er vaak ook een apart technisch team voor nodig, omdat de technologie en manier van ontwikkelen van Drupal tegenover pakweg Angular of React, heel anders is.

Doordat het werkt op basis van het consumeren en verrijken van data via Drupal API, mist het ook bepaalde andere functies van een Drupal applicatie. Zo bevat Drupal een zeer krachtige Webformulier module, die je niet zal kunnen gebruiken als je voor een volledige headless setup kiest. Ook indien je later een module wil installeren om bijvoorbeeld SEO optimalisatie te gaan doen in je CMS, is de kans groot dat je opnieuw (dure) ontwikkeling zal moeten doen aan de frontend kant om die optimalisatie ook daar in te krijgen.

Last but not least. Op dit moment werkt een headless Drupal (en evengoed een ander CMS) ook beperkend voor content editors. Het bepalen van de content weergave is niet of nauwelijks mogelijk, omdat de weergave in een volledig losgekoppelde applicatie zit. Dit is voor de meeste marketing teams de voornaamste showstopper als het gaat om headless websites.

Voordelen

  • Snelle, vloeiende gebruikerservaring
  • Zeer performante frontend
  • Door de loskoppeling kan je enkel je frontend app vervangen en het CMS behouden

Nadelen

  • Beperkend naar layout editing door marketing teams
  • Duurder in ontwikkeling
  • Duurder in support
  • Het project krijgt een grotere technische voetafdruk
     
Progressive decoupled

Progressive Decoupled is het antwoord

Op dit moment is het in verreweg de meeste gevallen af te raden om je Drupal website helemaal headless op te bouwen. Tenzij je Drupal gebruikt als data store voor een zeer specifieke case (business applicatie, process management) is het dus geen goed idee. Je verliest teveel voordelen van het gebruik van Drupal.

Er bestaat een tussenvorm, die we progressive decoupled noemen. 

Met deze oplossing gaat Drupal nog steeds zorgen voor het genereren van de webpagina's, maar kan je in je project de keuze maken om een deel van een webpagina toch te voorzien van een dynamische javascript oplossing. Dit combineert het beste van beide opties: Drupal zorgt nog steeds voor het genereren van de HTML pagina, dus alle voordelen van je CMS worden behouden. Specifieke delen van je pagina worden, eens geladen, een dynamisch geheel en zorgen zo dus voor die vloeiende gebruikerservaring waar we naar streven.

Goede voorbeelden van zo'n use cases zijn bijvoorbeeld het weergeven van complexe data zoals weerkaarten, sportuitslagen, en andere zeer specifieke "widgets". Ook het voorzien van een complexe zoekervaring kan daar baat bij hebben.

Wist je dat?

De vraag of een vorm van decoupling geschikt is voor jouw project wordt geanalyseerd in de platform strategie. 

Combineer beiden voor een omnichannel aanpak

De meest efficiënte oplossing is in een omnichannel context is de combinatie van beiden. Gebruik Drupal met een traditionele of progressive decoupled frontend voor je website en gebruik de Drupal API om data te beheren en aan te bieden aan andere media zoals je smartphone apps, kiosken, banners,...

Heb ik dan een javascript framework nodig?

Dat is de vraag binnen de vraag. Dat wordt per project afgewogen. Is het de moeite waard om de technische complexiteit van een apart javascript framework op te nemen in m'n project om enkele dynamische features te ontwikkelen. Soms kan het beter zijn om dat niet te doen, en je te beperken tot een kleinschaligere javascript oplossing. 

I am confident that adopting a client-side framework through progressive decoupling will give us the best of both worlds.
Dries Buytaert
 / 
Drupal Founder
Dries Buytaert

In een reeks artikels omtrent dit onderwerp geeft Dries Buytaert, bedenker van Drupal CMS en oprichter van Acquia, zijn visie over de toekomst van deze vlotte gebruikerservaring. Hij stelt er de vraag hoe we dit optimaal kunnen aanpakken als opensource-community, en welke keuzes we daarbij moeten maken.

Vandaag weten we dat Headless Drupal een goede toepassing is om deze redenen:

  • In een multi channel aanpak past Drupal 8 perfect in als CMS, dat content centraal beheert en deze content via Rest API beschikbaar stelt aan apps, websites en andere toepassingen
  • In sommige gevallen is het wenselijk om een headless setup toe te passen: frontends die data verzamelen uit verschillende bronnen hebben hier baat bij, alsook toepassingen waar snelheid en User Experience tot in het kleinste detail worden uitgepuurd.

Heb je vragen over headless CMS systemen? Of wil je graag jouw project even bespreken met een expert?
 

embed