-

Headless: de nieuwe standaard in CMS

Hoewel Content Management Systemen (CMS) al lange tijd meedraaien, is er de afgelopen jaren een serieuze verandering in het aanbod opgetreden. En wel in de vorm van het headless CMS. Bij een dergelijke nieuwe ontwikkeling komen gewichtige keuzes kijken. Spring je als bedrijf op de headless trein? En zo ja, welke voordelen sleep je daar dan uit? Wat zijn eigenlijk de verschillende opties en wat is het toekomstbeeld? Belangrijke en terechte vragen. Daarom nemen we je graag mee in de wereld van Headless CMS en bespreken we alle voor- en nadelen. 

Laten we beginnen bij de basis: wat is precies het verschil tussen een klassiek CMS en een headless CMS? In een klassiek CMS zitten zowel de frontend (design) als de backend (content) gezamenlijk in één systeem. Bedrijven kiezen doorgaans voor dit soort grote suites, zoals Sitecore en Optimizely, omdat ze een one-stop-shop oplossing bieden en website beheer toegankelijk maken voor het hele bedrijf. Iedereen – van developers tot het senior management – hoeft maar met één entiteit te dealen. Tegelijkertijd betekent dit dat developers zich voor een groot deel moeten houden aan de structuur die het CMS met zich meebrengt. Een lastige opgave in een wereld die vandaag de dag overheersend digitaal is. De gemiddelde digitale business behoeft hierdoor een groot aantal verschillende producten om te voldoen aan de verwachting van de consument. Dit vraagt om makkelijke integratie met SaaS-producten en het kunnen bouwen van systemen met producten die het beste aansluiten op de business. 

En zie daar, headless komt om de hoek kijken. Een headless CMS scheidt simpel gezegd de frontend en backend van elkaar. In het CMS zit alleen de content die op verschillende platformen geplaatst kan worden. De backend is namelijk een API. Zo kunnen blogs vanuit de back-end op een website worden geplaatst, maar bijvoorbeeld ook in mobiele apps. Onder andere om deze reden is headless inmiddels het speerpunt van grote digital experience platformen (DXP). Toonaangevende merken zoals Adobe en Optimizely gaan ook op de headless tour en wie als innovatief wil worden gezien moet mee. 

De voordelen van een headless aanpak

Headless CMS gooit het klassieke CMS dus op de schop met een scheiding van de frontend en backend. Uit zo’n breuk met traditie vloeien verschillende voordelen voort. Tijd om ze op een rij te zetten. 

1: Separation of concerns
We kunnen het niet vaak genoeg benadrukken: zeg je headless, dan zeg je scheiding. Het platform waar de content beheerd wordt, is dus gescheiden van het platform of kanaal dat de content serveert. Headless CMS is dan ook bij uitstek geschikt voor bedrijven die in meerdere kanalen publiceren of gebruik maken van interactieve websites of apps. Zo zien we steeds vaker dat applicaties niet slechts een website zijn, maar een single page of mobiele app. Dit betekent ook dat content voor meerdere kanalen kan worden ingezet, want kanalen zijn gescheiden van contentbeheer. Binnen de verschillende concerns kun je focussen op wat binnen dat onderdeel moet gebeuren zonder ballast te hebben van een ander domein waar je rekening mee moet houden. Het CMS fungeert op deze wijze als een content hub: content wordt centraal gemanaged en vanuit daar gepubliceerd naar verschillende kanalen. Dit leidt er tevens toe dat content eenvoudig is te hergebruiken. 

2: Apart schalen van kanalen
Een ander voordeel dat headless met zich meebrengt, is het apart kunnen schalen van kanalen afgestemd op de belasting van dat kanaal. Wanneer je content beheert op een bepaalde plek, moet deze plek geschikt zijn voor de belasting die daarop plaatsvindt. Bereikt je content bijvoorbeeld een groot publiek, dan kan je dit kanaal van extra capaciteit voorzien zonder dat het headless CMS mee moet dimensioneren. Vaak zijn de websites of applicaties zelf ook niet zo zwaar – het is het klassieke CMS dat het zwaar maakt. Het heeft veel kracht nodig om maar een heel klein stukje head te faciliteren. Dit zware onderdeel is via headless apart te zetten en vervolgens kan je de website desgewenst opschalen of applicaties toevoegen die het publiek bedienen. 

3: Optimale techniek per kanaal bepalen
Doordat kanalen te scheiden zijn kun je voor ieder kanaal apart bepalen welke techniek je gebruikt. Daarbij communiceer je via universele API-protocollen zoals RESTful of GraphQL. De techniek van die ene website van twee jaar geleden hoef je daardoor niet toe te passen op de nieuwe campagnewebsite. Je team zit dus ook niet vast aan één techniek met de uitdaging om daar telkens weer specialistische kennis voor in te huren. In plaats daarvan kan je het team uitbreiden op basis van de laatste innovaties. Wanneer je echter een website bouwt op een klassiek CMS, zal je altijd gebonden zijn aan de tech stack van het CMS. 

4: Beperktere vendor lock-in
De vrijheid van niet meer aan een tech stack gebonden zijn werkt ook de andere kant op. Wanneer je een nieuw CMS wil inzetten, kan je tot in grotere mate dat onderdeel in je landschap separaat vervangen terwijl bestaande websites behouden blijven zoals ze zijn. Je hoeft dus niet het kind meteen met het badwater weg te gooien. Zo kan je je bestaande CMS vervangen door modernere techniek of door SaaS als het eerst on-premise was. Dit kan wat voeten in de aarde hebben, omdat je bij de overgang naar een nieuw CMS de content daar wellicht opnieuw moet inrichten. Maar als de frontend goed is opgebouwd hoef je in principe alleen de query’s aan te passen. Met headless is het CMS bovendien niet langer leidend binnen het online kanaal en slechts een content bron. Zo kun je op een veel logischere manier content aggregeren met andere databronnen binnen de frontend applicatie. 

5: Beveiliging
Een laatste en belangrijk voordeel is dat door het ontkoppelen de mogelijkheid ontstaat het CMS verder naar achter in het landschap te zetten. Hoe minder raakvlakken met internet wat betreft de code, hoe kleiner de impact op security. Want hoe dunner de frontend applicatie, hoe minder ontsloten is naar het publieke domein.

Content uitdagingen

Kies je voor een headless CMS en daarmee de opzet als content hub, dan kies je er ook voor om de beschikbare content los te zien van je website of ieder ander kanaal. Contentcreatie neemt daardoor opeens hele andere vormen aan. Dat brengt de volgende uitdagingen met zich mee. 

1: Previewen van kanalen
Veel grote platformen en klassieke CMS’en bieden de mogelijkheid om content voorafgaand aan de publicatie te previewen op verschillende devices. Met de komst van headless, en alle verschillende kanalen waarop content verschijnt, is deze optie niet langer vanzelfsprekend. Dit gebrek is te ondervangen door in de cloud een parallelle omgeving te creëren die dient als een permanente review site, maar introduceert een complexere infrastructuur. Om dit te ondersteunen hebben headless leveranciers ook een publicatie workflow ontworpen, waarmee content in verschillende versies is op te vragen. Daarnaast excelleren klassieke CMS-platformen op het gebied van on page editing – iets dat voor een headless CMS juist een struikelblok vormt omdat er niet per definitie een pagina is. Hier is in de afgelopen jaren gelukkig aardig wat vooruitgang in geboekt en sinds eind 2020 behoort context editing middels software development kits nu ook voor headless tot de mogelijkheden. 

2: Zoekmachineoptimalisatie
Een headless CMS heeft content items in plaats van pagina’s. Omdat dit soort systemen zich meer profileren als content hub en agnostisch zijn qua gebruik, is het belangrijk om te zorgen dat crawlbaarheid en URL-structuren op orde zijn. De meeste oplossingen bieden inmiddels de mogelijkheid om metadata aan content items toe te voegen, waardoor je kunt kiezen voor welk kanaal je SEO-data wil toevoegen en hoe de URL-structuur er per kanaal uitziet. Andere systemen, zoals Umbraco en Kentico, werken met navigatiebomen – dit is vooral voor marketingafdelingen erg prettig.

3: Aparte hosting per kanaal
Wanneer een platform geabstraheerd is in een separation of concerns, komt naar voren dat er niet altijd veel mogelijkheden zijn om vanuit dit platform weer te integreren met andere platformen. Bij een klassiek CMS is de website in het CMS gebouwd: vanuit hier is het eenvoudig om integraties te maken met andere platformen. Met een separation of concerns zul je buiten het CMS andere software moeten draaien om vervolgens die integratie op te tuigen. Dit kun je gelukkig op allerlei manieren hosten, bijvoorbeeld middels (micro) services op Azure, AWS, GCP of zelfs GitHub. Voordelig is dat ook hier weer aparte keuzes voor techniek en dimensionering gemaakt kunnen worden zonder de overige onderdelen binnen het landschap te raken.

De opties afwegen

Heb je de knoop doorgehakt en je zinnen gezet op een headless CMS? Dan is de vraag voor welk systeem je kiest. Welke keus je ook maakt, ieder headless CMS biedt instapmodellen die vervolgens uitgebreid kunnen worden. Opschalen en het toevoegen van features is dus vrij eenvoudig, in tegenstelling tot de klassieke variant waar vaak dure licenties van afgenomen moeten worden alvorens je kunt beginnen. Verder kennen de opties kleine verschillen die doorslaggevend kunnen zijn voor je keuze. Zo lijken sommige headless systemen een directe vervanger van de grotere DXP-platformen. Deze zijn meer gericht op workflow management en meertaligheid. Anderen focussen zich met name op de content stack. Contentful richt zich bijvoorbeeld meer op developers. Prismic is een kleiner CMS dat zeer geschikt is voor bedrijven die met niet al te veel content dealen. Umbraco Heartcore is het headless zusje van Umbraco en catert daardoor heel erg aan mensen die al bekend zijn met Umbraco. Kentico Kontent levert een goede gebruikservaring op het gebied van context editing. Belangrijke differentiators zitten dus vooral in de focus van het platform. 

Here to stay?

Tot slot werpen we een blik op de toekomst. We maakten al duidelijk dat headless inmiddels geen trend meer is, maar is het here to stay? Wij geloven van wel. Mede dankzij de mogelijkheden om content via allerlei kanalen uit te serveren, verwachten we dat headless CMS op den duur de standaard wordt en grote klassieke CMS-platformen de omslag naar headless moeten maken om innovatief te blijven en bestaansrecht te houden. Door de komst van headless CMS zal ook de CMS-specialist uiteindelijk verdwijnen. Headless biedt engineers namelijk veel meer technologische mogelijkheden en zorgt ervoor dat ze sneller kunnen ontwikkelen. Headless wordt zo een overbodige term – de volgende generatie van DXP platformen zal namelijk volledig headless zijn. In een services oriented landschap waarin content een onderdeel is wat allerlei kanalen bedient, zal headless binnen no time de regel vormen en niet langer de uitzondering.

Praktijkvoorbeeld: Takeaway x headless

Toen Thuisbezorgd.nl, de Nederlandse tak van Just Eat Takeaway.com, in 2000 het levenslicht zag werd het al snel een groot succes. Fast forward naar 2020: het populaire bedrijf wilde haar b2b-webshop transformeren tot een innovatieve marketplace en Dept schoof als partner aan. De vernieuwde webshop heeft de focus om als een marketplace voor restauranthouders te dienen, waarbij zij van alle gemakken voorzien zijn en zowel food als non-food kunnen bestellen. Het hele b2b platform bestaat uit een headless-opzet. Dit biedt de mogelijkheid om de best passende oplossing te kiezen voor het CMS-deel. Zo is ervoor gekozen om het bestaande platform van Magento te migreren naar Commercetools (commerce/PIM engine) en Prismic (CMS voor webshop content). Dit brengt meteen het voordeel met zich mee dat andere kanalen dan de huidige b2b-webshop eenvoudiger aangesloten kunnen worden op eenzelfde commerce-omgeving – wat weer mogelijkheden biedt voor toekomstige uitbreidingen.

Over de auteur: Jasper Steenweg is lead technical consultant en architect bij Dept Agency.

Op de hoogte blijven van het laatste nieuws binnen je vakgebied? Volg Emerce dan ook op social: LinkedInTwitter en Facebook.

Deel dit bericht

Plaats een reactie

Uw e-mailadres wordt niet op de site getoond