Headless Drupal: wat is het, wanneer kies je ervoor en hoe werkt het?

Het verschil met traditioneel Drupal

Bij een traditionele Drupal-opzet doet Drupal alles. De redactie vult content in, Drupal verwerkt die via een Drupal template en levert webpagina’s aan de browser. Dat werkt al jaren goed en is voor veel projecten een prima keuze.

Bij een headless opzet stopt Drupal bij het opslaan en aanbieden van content. Een aparte frontend-applicatie, haalt de content via de API op en bouwt daar de pagina mee op. Drupal hoeft niets te weten over hoe de website eruit moet zien, het levert alleen de data.

Het bekendste voorbeeld in onze portfolio is het JobBoard van de Universiteit van Amsterdam. Drupal beheert daar de vacatures, stages, bedrijfsprofielen en goedgekeurde stages per studie, terwijl een frontend applicatie de interactieve gebruikersinterface verzorgt.

Wanneer kies je voor headless Drupal?

Er zijn een paar situaties waarin headless echt meerwaarde geeft:

• Je hebt meerdere kanalen die dezelfde content nodig hebben. Denk aan een publieke website plus een mobiele app, of een portaal voor medewerkers en een aparte app voor klanten. Headless laat je een centrale content-bron bouwen die alle kanalen voedt, met een eigen Look&feel per kanaal/applicatie.
  
• Je wilt een rijke, interactieve gebruikerservaring. Voor toepassingen met realtime updates, complexe formulieren, drag-and-drop of veel client-side interactie loop je met traditioneel Drupal sneller tegen grenzen aan dan met React of Next.js, die daar nu eenmaal voor gemaakt zijn.
  
• Je verwacht in de toekomst van technologie te wisselen. Door content los te koppelen van presentatie krijg je flexibiliteit, en daar gaan we onder "Onafhankelijkheid en toekomstbestendigheid" verderop dieper op in.

Wanneer juist niet

Headless is geen doel op zich. Voor veel projecten voegt het complexiteit toe zonder duidelijk voordeel. In deze gevalle kun je beter niet kiezen voor headless:

• Je hebt een redelijk standaard website. Een corporate site, een blog, een portfolio of een wat grotere informatiesite werkt uitstekend in traditioneel Drupal. Het is sneller te bouwen, makkelijker te beheren en goedkoper in onderhoud.
  
• Je development team heeft beperkte JavaScript-ervaring. Headless Drupal vereist developers die comfortabel zijn met moderne JavaScript-frameworks en bouwprocessen. Mis je die expertise, dan duurt elk project langer en kost het meer.
  
• Je hebt strakke deadlines en een beperkt budget. Twee gescheiden codebases, twee opleverroutes en twee plekken om in de gaten te houden vragen meer voorbereiding en meer onderhoud. Voor een eenvoudige website is dat zelden de moeite waard.
  
• Je hebt redacteuren die WYSIWYG-controle willen. Bij headless verlies je de directe koppeling tussen wat een redacteur in de editor ziet en hoe het op de site verschijnt. Met een goede preview-omgeving is dit op te lossen, maar dat vraagt wel extra werk.

Welke frontend frameworks combineer je met Drupal?

Drie keuzes komen we het vaakst tegen, en de afweging tussen die drie hangt af van wat je team kent en wat je wilt bereiken.

React is veruit het meest gekozen. Groot ecosysteem, veel beschikbare developers, breed gedragen patronen. Ideaal voor interactieve interfaces en applicaties die aanvoelen als software in de browser. We hebben een dienstpagina speciaal voor React development waarop we onze aanpak verder uitleggen.

Next.js bouwt voort op React en voegt mogelijkheden toe om pagina’s al op de server klaar te zetten in plaats van pas in de browser, plus een ingebouwde manier om data uit te wisselen. Voor headless Drupal-projecten waarbij SEO en performance belangrijk zijn, is dit vaak onze voorkeurskeuze. Meer hierover in ons artikel wanneer kies je voor een decoupled website met Next.js en in onze update over de nieuwe toolbox van React 19.

Vue.js is wat lichter dan React, voor sommige teams ook makkelijker om mee te beginnen, en voor veel toepassingen net zo geschikt. We zetten het in op verzoek of als de bestaande infrastructuur dat al gebruikt, maar het is niet onze standaardkeuze.

Een laatste opmerking: Drupal is niet de enige headless backend die we gebruiken. Voor projecten die nieuw beginnen zonder zware redactionele eisen kijken we ook naar Payload CMS, dat van origine als headless CMS is opgezet. Welke backend het beste past, hangt af van wat je content-team gewend is en hoe complex je content-model is.

Headless Drupal in de praktijk bij Emble

Bij elk nieuw project stellen we eerst de kritische vraag: hebben we headless echt nodig? Die afweging maken we open en transparant samen met de opdrachtgever. Een paar voorbeelden uit onze Drupal development-projecten waar headless wel de juiste keuze bleek:

Bij het JobBoard van de UvA gaf de combinatie Drupal-en-React precies de balans die we zochten. Drupal beheert duizenden vacatures, stages en bedrijfsprofielen, terwijl React zorgt voor de zoek- en filterervaring die studenten verwachten.

Bij andere projecten kozen we juist bewust voor traditioneel Drupal of een combinatie. Bij het Monumentenregister van Cultureel Erfgoed was Drupal puur als content-platform de betere keuze.

Deel dit artikel