Headless: waarom je CMS en frontend apart moet houden

Bij het soort projecten dat Enrise doet, loop je gauw tegen de beperkingen aan van traditionele contentmanagementsystemen. De eisen die onze klanten stellen aan performance, flexibiliteit en klantervaring, plus de behoefte aan aanpassingen, zorgen dat we meestal kiezen voor een headless CMS. Maar wat is headless nou precies? En wat zijn de voor- en nadelen? In dit artikel zet ik het voor je op een rij.

‘Headless’ is een term die meestal gebruikt wordt voor een CMS dat geen eigen presentatielaag heeft en waarbij representatie (frontend) en content (backend) dus in aparte systemen zitten. Bij Enrise bouwen we graag systemen met een duidelijke scheiding tussen alle systeemlagen, ook wel bekend als decoupled of niet-geïntegreerde systemen. Want als je klantervaring, proces en opslag los van elkaar ontwikkelt, heeft dat veel voordelen. Het werken met een headless CMS is een belangrijk deel van deze aanpak. 

Snelheid 

Het eerste voordeel van headless is snelheid. Wat is een ‘snelle’ site of app? Die definitie is voor iedereen anders. Als een contentredacteur een afbeelding uploadt, mag dat best een paar seconden duren. Maar een webshopbezoeker die een paar seconden op het bestelscherm moet wachten, is vertrokken. Een traditioneel, geïntegreerd CMS geeft contentredacteur en eindklant dezelfde snelheid en dat willen we vaak niet. Door cms en presentatielaag van elkaar los te trekken kunnen we een razendsnelle website bouwen die zich puur richt op de klantervaring. 

Met de huidige trend naar single page applications (SPA’s) zijn headless systemen helemaal onmisbaar geworden. Data in webpagina’s wordt in steeds kleinere ‘brokjes’ ververst. Dat geeft vooral e-commercesites een ‘app-achtig’ gevoel, dat mensen kennen van sociale media en mobiele apps. Een doelgroep die dat gewend is, kun je niet meer op een pagina-refresh laten wachten. Daarom bouwen we steeds meer logica in de frontend en gebruiken we de backend steeds meer ‘asynchroon’, dus los van de interactie met de gebruiker. Met een volledig geïntegreerd CMS is dit moeilijk voor elkaar te krijgen. 

Flexibele schaalbaarheid 

Een ander voordeel is dat je ontkoppelde systemen per component kunt schalen. Als de voorkant zwaar belast wordt, hoef je alleen die op te schalen. Omgekeerd geldt hetzelfde: als de backend het zwaar heeft, bijvoorbeeld omdat we grote hoeveelheden content aan het uploaden zijn, heeft dat geen impact op de klantervaring. Zo gaan we efficiënt met resources om, terwijl we alle gebruikers optimaal kunnen bedienen. Ook dat is lastig, als je voor- en je achterkant vast met elkaar verbonden zijn. 

Development en onderhoud 

Een systeem dat uit losse componenten bestaat is makkelijker te onderhouden dan een monolithisch systeem. Front- en backend development zijn bovendien verschillende disciplines. Daardoor komt het vaak voor dat er aan de voor- en de achterkant van een project verschillende teams of zelfs verschillende bedrijven werken. Dat gaat heel goed als je ontkoppelde systemen maakt die je met API’s aan elkaar verbindt. 

Je kunt dit soort systemen ook in delen bouwen of vervangen. Je kunt overschakelen naar een nieuw headless CMS of e-commerceplatform, zonder de bestaande websites en apps aan te raken. Op voorwaarde natuurlijk dat het nieuwe systeem dezelfde data levert in hetzelfde formaat. Ook kun je gefaseerd nieuwe functionaliteiten toevoegen. Wij gebruiken een CMS graag om content te beheren, want daar is het voor gemaakt. Als we andere functies nodig hebben, zoals authenticatie of databeheer, dan bouwen we die in een systeem naast het CMS. We kunnen ze dan in de frontend integreren, zonder iets aan het cms te hoeven doen.

Meerdere frontends (of meerdere backends) 

Een grote e-commercepartij met twee merken vroeg ons om twee webwinkels voor ze te bouwen, met alle producten in één database. Dat is typisch een project voor een headless systeem. Door één backend te bouwen en twee verschillende frontends, bespaar je veel op je development- en onderhoudskosten. Businessgebruikers hoeven ook nooit meer content te updaten in twee verschillende systemen, wat het werk in multi-merk e-commercebedrijven veel efficiënter maakt. 

Omgekeerd werkt het hetzelfde: één frontend kan meerdere backends hebben. Dat is vooral handig bij e-commercesites die ook content publiceren. Door een e-commerceplatform aan te vullen met een headless cms kunnen we content naadloos in de site opnemen, zonder hem te hoeven beheren in een platform dat daar helemaal niet voor bedoeld is. Dat scheelt heel veel workarounds en hoofdpijn.

Headless e-commerce

De voordelen van headless zijn dus niet beperkt tot contentmanagementsystemen. E-commerceplatformen als Shopware laten zich goed headless inzetten. Sylius, een open source product, is zelfs volledig headless en API-based.

E-commercesoftware valt uiteen in platformen en frameworks. Een platform levert meteen, zonder development, de basisfunctionaliteiten voor e-commerce. Een framework bestaat uit losse, functionele ‘legoblokjes’, die je zelf nog samen moet voegen tot een toepassing. Onze ‘Whitepaper E-commerceplatforms’ gaat veel dieper in op de verschillen en de verschillende varianten, als je dat interessant vindt. 

Over het algemeen kun je stellen dat een e-commerceframework beter te gebruiken is in headless systemen dan een e-commerceplatform. Bij een framework kun je namelijk zelf kiezen welke stukken je wel en niet gebruikt in je project. Eventuele uitbreidingen kun je dan heel goed modulair toevoegen, waarna je de modules via API’s verbindt. De headless inzetbaarheid van pakketten verschilt enorm. Magento is bijvoorbeeld een heel stuk lastiger headless op te zetten dan Shopware.

De kosten van headless 

Het grote nadeel van headless kun je nu ook al wel raden. Headless systemen zijn ingewikkelder om te maken, dus maak je initieel ook meer kosten. Dat maakt headless werken niet altijd de beste optie. Heb je een content- of marketingsite nodig en heb je verder geen plannen voor apps of integraties? Dan ben je waarschijnlijk beter af met een geïntegreerd cms en een mooi thema.

Ook in het gebruik hebben headless CMS’en uitdagingen. Denk bijvoorbeeld aan het previewen van content. Bij een geïntegreerd cms kan dat out of the box, maar bij headless moet je daar vaak zelf iets voor bouwen. Bij multimerk-toepassingen en/of meerdere frontends moet je je dan ook nog afvragen in welke styling je de preview gaat weergeven. De meest praktische oplossing is dan vaak om een soort ‘algemene styling’ te ontwikkelen die een algemeen beeld geeft van hoe content er in de presentatielaag uit komt te zien. Zo’n styling is dan natuurlijk wel volledig responsive en mobile first uitgedacht. 

Headless CMS’en 

Het aantal headless contentmanagementsystemen is inmiddels enorm en ik ga hier geen volledige lijst voor je maken. Het is met een headless cms zoals met alle projecten: je moet het platform kiezen dat bij de toepassing, het project en de organisatie past. Er is niet één headless cms dat alle klussen aankan. Dit zijn de systemen waar we hier bij Enrise inmiddels ervaring mee hebben: 

• WordPress: van origine een open source geïntegreerd blogplatform, maar inmiddels uitstekend ontkoppeld te gebruiken. Een robuuste keuze voor meertalige projecten, met een grote community en een groot ecosysteem. 
• Drupal: ook niet headless van oorsprong, maar met de tijd meegegaan. Geschikt voor complexe contentprojecten. 
• Craft CMS: een oplossing op basis van open source technologie, met ingebouwde preview-functionaliteit en een prettige, moderne redactie-omgeving. 
• Contentful: een gebruiksvriendelijk SaaS-systeem met veel functionaliteit. Aan de prijzige kant. 
• Home made: voor lichte toepassingen hebben we een zelfgebouwd cms op de plank liggen. Want zo ingewikkeld is het nou ook weer niet. 

Meer weten over het kiezen van een CMS? Lees ook het blog ‘Hoe kies je een CMS voor je volgende project?’