Headless CMS’en: ‘Ja, een hype. Maar dat is niet slecht’

Er wordt vaak aangenomen dat ontwikkelaars blij zijn met zogenaamde headless CMS’en.  Een gewoon content management systeem zou ze te log, te complex en te beperkend zijn. Hoe denkt een ontwikkelaar daar zelf eigenlijk over? “Het is een hype. Maar dat is niet iets slechts.”

In tegenstelling tot een traditioneel content management systeem levert een headless CMS de inhoud niet af bij de eindgebruiker. De inhoud wordt via een API richting een interface gedistribueerd. Vooral ontwikkelaars schijnen hier nogal blij mee zijn omdat het de flexibiliteit vergroot. Het CMS en de content zijn geschikt voor ieder denkbaar kanaal en de ontwikkelaar wordt niet geremd door de front-end-beperkingen van een standaard CMS.

De daadwerkelijke eindgebruiker merkt weinig van de keuze voor een headless CMS. Die bewerkt zijn content in een gebruiksvriendelijke webtool, de content wordt vervolgens waar nodig afgeleverd. Een headless CMS moet dus eigenlijk gezien worden als een nieuwe service: Content as a Service. Bekende namen op dit vlak zijn Confentful, Directus, Built.io en Kentico Deliver.

Een CMS dat nog een stapje verder gaat is Instant, hier eerder beschreven op Emerce. Hiermee is de inhoud van een site in-line, vanuit de browser zelf, te veranderen. Voor het draaien van dit CMS is niet eens servercapaciteit nodig. Die capaciteit wordt op afroep afgenomen via de ‘serverless’ oplossingen van Amazon en Google.

‘De hype is waardevol’

Dergelijke headless CMS’en krijgen dus nogal wat aandacht en voordelen toegedicht. Maar is dat terecht? Of is er sprake van een hype? “Het is zeker een hype”, zegt Erik Westra die als Lead Developer werkt voor Kaliber. “Want vroeger heette dit gewoon Content Repository”, reageert hij. “Een bekend voorbeeld daarvan is Hippo dat gebaseerd is op Apache Jackrabbit uit 2004. Maar is een hype daarmee iets negatiefs? Ik denk het niet. Er zit vaak meer waarde in dat je zou denken. Voor mij betekent een hype namelijk ook dat een groter publiek open staat voor het gebruik ervan.”

De situaties waarin een headless CMS uitkomt zijn reeds beschreven. Wil iemand niet-webcontent publiceren, dat multichannel doen of bepaalde inhoud aggregeren dan is zo’n onthoofd CMS inderdaad een optie. Daarnaast ziet Westra nog één heel belangrijke plus: applicaties moeten vandaag de dag schaalbaar zijn. Neemt door een marketingcampagne ineens de load toe, dan moet de capaciteit zijn uit te breiden. “Met een traditioneel CMS is dit wel mogelijk, maar ze zijn er eigenlijk niet voor gemaakt. Het levert veel meer gedoe op. Met een headless CMS is het makkelijker om dat deel van de site waar veel gebruikers komen op te schalen.”

Een dergelijk soort CMS gebruiken voor het beheren van websites ligt veel minder voor de hand. “Daarvoor is het vrijwel nooit nodig. Content wordt nooit één-op-één beschikbaar gemaakt in een ander kanaal.” Bij de meeste bedrijven is de content namelijk niet het belangrijkste, maar de conversie. “Om die conversie te optimaliseren spits je content toe op een specifiek kanaal. Je zou kunnen zeggen dat zo’n CMS het hergebruik van content zelfs aanmoedigt. En dat heeft een negatief effect op de conversiecijfers.”

‘Niet automatisch kiezen voor headless’

Maar hoe enthousiast ontwikkelaars ook zijn over de flexibiliteit die ze wordt geboden, zou de keuze voor een CMS in Westra’s ogen niet automatisch moeten leiden tot een oplossing als Contentful. “Gebruik het echt alleen als het de beste keuze is voor de oplossing die je als ontwikkelaar wil aanbieden. Het geeft vrijheid, maar maakt andere onderdelen veel moeilijker.”

Een van de grootste problemen vindt hij bijvoorbeeld dat de structuur van de content vaak niet kan leven naast de code van de applicaties. Maken een website en mobiele app gebruik van dezelfde content dan draaien de codes naast elkaar, legt hij uit. “Je moet extra moeite doen om de structuur van de content in de website en app gelijk te laten lopen. Sommige headless CMS’en hebben wel een API voor, maar dat vraagt om extra stappen tijdens het uitbrengen van updates.”

Met name bij startups zou het enthousiasme iets te groot zijn. Jonge programmeurs bouwen bijvoorbeeld enthousiast aan ‘single page applications’ (SPA’s) – websites waarbij de gebruikersinterface met javascript wordt getekend. “Vaak wordt er pas tegen het einde van het project nagedacht over het delen van pagina’s op sociale media en de indexatie door Google en andere zoekmachines. Hiervoor is het belangrijk dat de site op de opgegeven URL daadwerkelijk content serveert. Met een SPA wordt die content door javascript uit het headless CMS opgehaald en is dat dus niet het geval.” Bij bedrijven met ervaren programmeurs is daar vaak in een eerder stadium al aan gedacht denkt Westra. “Dat er nu zoveel over wordt geschreven maakt het praten over de voor- en nadelen in ieder geval makkelijker.”

‘Goed stuk gereedschap’

Al met al is er bij Kaliber regelmatig mee geëxperimenteerd, maar is het niet vaak de uitkomst gebleken. Westra ziet een headless CMS vooral als een goed stuk gereedschap in zijn gereedschapskist.

“Als goed bureau help je bij het kiezen van een oplossing die past bij het vraagstuk en het budget. Alleen voor het beschikbaar maken van content in apps is dit dit een verbetering, maar weegt het in mijn ogen niet op tegen de voordelen van een traditioneel CMS. De meeste CMS’en beschikken namelijk over een API om de content op een andere manier beschikbaar te maken. Kiezen voor een maatwerkoplossing die de content met andere bronnen verweeft is meestal slimmer dan een nieuw type CMS met bijbehorende leercurve.”