De term ‘headless cms’ duikt regelmatig op. Het staat voor een nieuw type cms dat een ideale inrichting kent voor alle soorten digitale kanalen en devices. Wat is zo’n headless cms? En vanwaar de commotie?
Het contentmanagementsysteem (cms) is vanaf de jaren negentig een sleutelcomponent bij de ontwikkeling van het wereldwijde web. Designers, redacteurs, e-commercemanagers en marketeers zochten naar software waarmee ze makkelijk content op een website konden plaatsen, beheren en de digitale ervaring van klanten konden beïnvloeden, zonder dat ze daarvoor direct naar de it-afdeling hoefden te stappen.
Aan die rol van het cms is niet veel veranderd. Wel is een en ander veranderd in de wijze waarop we met internet omgaan. En dat heeft ook de nodige consequenties voor het cms.
- Meer sites
Bedrijven hebben steeds meer sites en vaak ook sites die enkel gebruikt worden voor een tijdelijke marketingcampagne. Er is daardoor een grote behoefte aan een cms dat snel en eenvoudig pagina’s genereert en er tegelijkertijd professioneel uitziet. Het aantal websites dat wereldwijd actief is neemt daardoor enorm toe. In 2017 waren er iets minder dan 1,75 miljard websites actief in alle soorten en maten, terwijl we er in 2014 nog minder dan een miljard hadden.
- Meer devices
Het oude cms was gericht op één type gebruikersscherm: de pc. Die wereld is in een tijdsbestek van tien jaar behoorlijk diffuus geworden door de komst van smartphones, tablets, laptops en iot.
- Nieuwe vormen van interactie
De eerste cms-en waren gericht op de publicatie van platte tekst. Video is in de loop van een aantal jaren sterk toegenomen. En zelfs voice-interfaces komen nu voor. Daarnaast is er ook steeds meer interactie met webgebruikers. Denk aan sociale media, fora, maar ook chatbots. Voor cms-en is het zaak al die vormen van content te ondersteunen.
- De cloud
It-bedrijven zijn de afgelopen vijftien jaar geleidelijk overgeschakeld van een on-premise verdienmodel naar een dienstenmodel gebaseerd op de cloud. Voor cms-leveranciers heeft dat ook belangrijke gevolgen. Web-omgevingen zijn te verrijken met allerlei clouddiensten.
- Analytics en kunstmatige intelligentie
Er zijn de afgelopen tien jaar enorme stappen genomen op het gebied van analyse van data en kunstmatige intelligentie (ai). De webomgeving is één van de beste plekken waar bedrijven voordelen kunnen halen uit die technologie. Met behulp van slimme inzet van ai is content op de website af te stemmen op de websitebezoeker, waardoor deze een gepersonaliseerde, op hem of haar gerichte website-ervaring heeft.
Voor het ‘klassieke’ cms vormen deze ontwikkelingen een uitdaging. Bij vrijwel alle oude systemen zijn de frontend-presentatie, interactie en vormgeving van content reeds vastgelegd in de backend-database. Dat betekent dat beheer van content en het cms sterk toeneemt zodra het aantal kanalen (smartphone, tablet, iot) en platformen (sociale media, e-commerce) toeneemt. Daar komt nog bij dat on-premise het dominante model is bij het klassieke cms. Gebruikmaking van cloudtechnologie of personalisatie-engines vraagt om on-premise aanpassingen.
Headless
Het headless cms is een poging van cms-leveranciers om deze ontwikkelingen te adresseren door de architectuur van het cms anders in te richten. Het cms hanteert een scheiding tussen de backend-database waar de content zich bevindt, en de frontend-presentatie-laag. Beheerders kunnen in de backend database content creëren, lezen, aanpassen en verwijderen. De content is vervolgens toegankelijk voor elk kanaal via restful api. Deze restful api (application programming interface) gebruikt het http-internetprotocol om data op te halen van een databron, in dit geval het cms. De presentatielaag bevindt zich niet bij de gebruiker… Vandaar ‘headless’.
Het voordeel van deze inrichting is dat elk kanaal is te gebruiken met zijn eigen unieke presentatiemogelijkheden. Een groot landschap aan verschillende devices en schermen is beter te bedienen. Een headless cms is bovendien geschikter (dan het klassieke cms) voor personalisatie. In het klassieke cms werd content ‘gepusht’ naar het kanaal. De gebruiker van het kanaal krijgt de content te zien ongeacht zijn situatie. Het headless model schrijft voor dat content wordt opgehaald (pull) door de applicatie. De api is zo in te richten dat dit gebeurt op basis van de context van het kanaal en de gebruiker. Sterker, een engine op basis van ai kan de gebruiker herkennen en zo onderzoeken of content wel of niet aanslaat bij die gebruiker op basis van zijn context.
Samenspel
En tot slot: headless zorgt voor een betere samenwerking met de it-afdeling. Beheer en onderhoud van een cms is altijd een samenspel geweest tussen gebruiker en it, waarbij de gebruiker meer let op de vormgeving en het dagelijkse gebruik en de it’er op de technische achtergrond. Het headless cms zorgt voor een logische scheiding tussen deze twee werelden. De technische component rond het beschikbaar stellen voor diverse kanalen wordt gemanaged door de leverancier. De content zelf en de customer experience van de websitebezoeker wordt beheerd door de gebruiker.
Er is geen twijfel dat het headless cms binnen afzienbare tijd vrijwel overal aan populariteit wint. Vrijwel alle leveranciers van cms zijn momenteel hun cms aan het aanpassen en in te richten op deze nieuwe manier. Uiteraard zal zo’n transitie geleidelijk gaan aangezien veel bedrijven nog websites gebruiken op basis van het ‘klassieke’ cms. Maar de ontwikkeling is onomkeerbaar. Bedrijven hebben de snelheid nodig die headless hen geeft om aanpassingen te maken aan de website.
Uiteraard ben ik benieuwd hoe jullie hier over denken. Wordt headless cms inderdaad dominant of zien jullie dit anders?
Nadat ik deze rijstebreiberg met marketing uitdrukkingen verorbert had, dacht ik “He, wat nu?”.
Dat doet toch iedere WordPress-installatie en ettelijke andere van de (300?) vrije CMSsen, omstandig omschreven herken ik HTML5, PHP, CSS, media-queries en javascript.
Dan even in het profiel van Matthias gekeken en de website van e-spirit, die verkopen een eigen CMS, zeg dat dan.
In ieder geval bedank voor de kreatieve tekst, ik wens me dat ik dat ooit leer.
Altijd lastig een nieuwe technologie (headless) uit te leggen als de oude (coupled, decoupled)
al zo veel interpretaties kent.
De auteur lijkt de oude techniek niet te kennen dus de termen coupled en tiered worden niet genoemd.
Ik zal het uitleggen. Belangrijkste doel is om te laten zien dat ik er veel van weet.
Bij traditioneel CMS zit de presentatie data vaak niet in de database maar minimaal gedeeltelijk in de webfrontend.
Bijv in PHP op webserver (thema templates implementatie) en gedeeltelijk in de database (gekozen thema)
Maakt het er niet duidelijker op.
Nog lastiger wordt het als coupled hier betekent dat Content Management en Content Delivery in 1
applicatie zitten, wat weer niet inhoudt dat zo’n coupled CMS geen database backend heeft.
Je kunt dus best een coupled multi tier CMS hebben, met een aparte database tier en apart webfrontend voor zowel content management als content delivery. Het Coupled slaat dan op dezelfde interface voor zowel inhoud wijzigen door content manager als inhoud leveren aan eindgebruikers.
Evenzo kan een decoupled CMS weer geimplementeerd zijn met een python django of ruby rails webserver met een database op dezelfde server, dus vanuit infrastructuur gewoon single tier.
Dwz als je met applicatie niet gewoon alles inclusief database bedoelt, de hele zooi.
Dan zijn er ook weer interpretaties waarbij de browser bijv in een aparte tier (client side) zit of nou juist samen met de webserver (server side) in de presentatie tier. Wat is nou coupled, wat is nou tiered ? Wat zit waar ? Decoupled not is headless, maar headless is wel altijd decoupled ?
Gelukkig heb je nog de verwarring dat een rest API defacto over HTTP gaat, maar dat het bij APIs
gaat om de data : JSON, YAML (immers Yaml Aint Markup Language), SOAP/XML.
Dus zie je een architectuur plaatje met een webserver dan zit die in de data tier of presentatie tier,
afhankelijk afhankelijk van de functie.
Ik kijk uit naar een artikel van de auteur over BodylessCMS.
A) valt het wel mee met de marketinguitdrukkingen, het zijn gewoon de termen die gebruikt worden.
B) het is niet hetzelfde als WordPress en de andere 300 gratis cms-en. Die werken bijna allemaal met een frontend waarvan de code bij het CMS staat. Er is een voorkant en een achterkant, op hetzelfde domein, vanuit dezelfde codebase. De twee zijn sterk vervlochten met elkaar en om de voorkant te veranderen zijn ook bijna altijd veranderingen aan de achterkant nodig. Het soms wel mogelijk om ze headless te maken, maar het is zeker niet de standaard en ook niet gebruikelijk.
Het idee van headless is dus om die 2 geheel te scheiden. Dat heeft een aantal voordelen en een aantal nadelen. Voordelen zijn dat het cms als bron kan dienen voor meerdere applicaties. Bijvoorbeeld een app, de hoofdwebsite maar ook sites van derden. Neem bijvoorbeeld vacatures. Als deze in het cms worden beheerd, dan kan de hoofddomein gebruik maken van die data, maar ook een andere vacaturesite zou de API kunnen gebruiken om die data in te lezen. Het is in theorie ook makkelijker om de voorkant in zijn geheel te vernieuwen inclusief andere URL’s. Sterker nog, een heel andere partij kan de frontend mqken. Maar daar zit gelijk ook een pijnpunt. Een headless cms kent een heel andere manier van werken en dat gaat er vaak maar moeilijk in. ‘Men’ is gewend om in een cms pagina’s in te richten, die in een bepaalde structuur vallen. Van oudsher maak je in het CMS echt de site, content, opbouw, navigatie. Als je echt headless wilt gaan moet je daarvan af. Je moet gaan denken in de C van content. Dat is ook wat een CONTENT management systeem eigenlijk hoort te doen. Je moet je domeinkennis opdelen in entiteiten en dat is wat je beheert. Je nieuwsberichten, vacatures, contactadressen, kernwaarden, etc. Je moet niet meer denken “Hoe komt dit er straks uit te zien?”, maar wat is de data die ik wil delen. Alleen dan maak je een echt headless systeem. En daar gaat het wel een beetje mis op dit moment. Die stap is vrij moeilijk. En dat is ook niet heel raar, want je verliest ook een stuk controle. De navigatie is bijvoorbeeld eigenlijk geen onderdeel van die data. En ook de pagina indeling en de structuur niet. Maar dat is wel iets waar gebruikers – terecht – vinden dat ze dat ook moeten kunnen beheren. Net als bijvoorbeeld een (live) preview. Iets wat ook niet echt bestaat als je echt een headless cms hebt. En daarom is mijn ervaring dat bedrijven vaak kiezen voor een soort hybrideoplossing. Wel een API, maar ook de structuur. En dat is niet perse slecht maar ook niet perse goed. Het laat het alsnog toe om 3e partijen makkelijk de data te absorberen, maar het CMS is wel meer verstrengeld met de frontendcode. Nog erger, de content wordt ingericht aan de had van de frontend. En daar stap je dus eigenlijk af van wat een cms zou moeten zijn. Een langdurig beheer van je bedrijfsdata.
Oftewel, voor- en nadelen. De keuze is aan de klant en die valt steeds vaker voor headless, maar de gevolgen worden niet altijd begrepen.
Headless is inderdaad de toekomst.
Drupal heeft de jsonapi in core inmiddels ingebakken. JavaScript front ends kunnen de content via de json api opvragen en hun ding doen. Drupal fungeert dan als een content store en niet meer als een monolitisch cms.
Wat een leuke discussie! En Dino die over de inhoud praat, het moet niet gekker worden!
Hier zijn mijn twee centjes… mede door de discussie en dat ik van de week tijdens een gesprek steeds headless CMS hoorde is nu het kwartje gevallen.
Wij hebben een headless Learn Management System (LMS) ontwikkelt. Niet dat we het ooit zo genoemd hebben. De leercontent is gescheiden van waar en hoe deze wordt getoond en iedereen kan onze API’s aanroepen (GraphQL) en zo zelf bepalen waar en hoe onze content eruit komt. Al moet ik eerlijk bekennen dat er toch wel wat opmaak elementen in de content zit of aansturing voor de interacties (HTML tags).
Een ander ding is dat wij AWS S3 buckets en CloudFront als Content Delivery Network gebruiken. Ik noem dit statische webpagina’s. Rete snel, veilig, goedkoop. In een los programma lokaal op een computer maak je die pagina’s op (noem het headless, haha) en als ik klaar ben druk ik op een knop, wordt er HTML van gemaakt en gepusht naar een S3 bucket die ingesteld staat om content te serveren als een webserver. Voorbeeld: https://rockpaper.app/ . Door wat serverless functies, JavaScript libraries en SaaS toe te voegen kan er toch een dynamisch geheel van gemaakt worden. Dus reacties, contact formulieren, Call to action, etc.
Een groot voordeel van deze aanpak is dat je geen servers hoeft te beheren, er weinig valt in te breken, het snel en goedkoop is. Nadeel is dat het lastiger te beheren is, uitdagingen in concurrency etc.
Maar leuke discussie! Thanks.
Dus wanneer ik webpagina’s maak met PHP dan ben ik headless bezig en kan ik het CMS noemen als die van een gebruiker gewijzigd kunnen worden.
Leuk om te weten.
Dino bedankt, dat was illustratief.
Hi Jan,
Als het serveren van een pagina door een PHP webserver moet gebeuren spreek je in mijn ogen niet over headless CMS. Als je een PHP programma maakt waarmee je content op kan slaan en dat die content geconsumeerd kan worden door andere systemen dmv een (REST / GraphQL) en hiermee webpagina’s kan serveren, dan praat je over headless.
Platgeslagen moet je headless dus lezen als; CMS systeem zonder front-end webserver. Of het loskoppelen van het tonen en opmaken van een webpagina.
Dan stel je jezelf de vraag: Welk probleem los ik op?
– Je scheidt expertises: Een tekstschrijver hoeft niets te snappen van webpagina’s. Een webdesigner kan zich richten op het zo mooi mogelijk presenteren van content op diverse devices met frameworks van zijn voorkeur
– Het beheren van de content staat los van de strategie om deze content in te zetten en wordt multi inzetbaar.
Voorbeelden:
– Als persbureau wil je de inhoud pushen met beeldmateriaal. Iedereen die een subscription heeft op die inhoud mag zelf bepalen wat en hoe deze getoond wordt.
– Beheerders van content bepaald wie waar toegang toe heeft, afnemers van content krijgen alleen te zien wat voor hun toegankelijk is.
– Als je tien ingangen hebt zoals CoolBlue vroeger dan kun je allemaal websites maken die gericht zijn op hun specifieke doelgroep, maar is er 1 systeem die gebruikt kan worden waarin alles gezet en beheerd wordt.
Als je WordPress en zelfs Drupal als voorbeeld neemt…. Deze kunnen niet zonder tools gezien worden. De content en het serveren van de content zijn sterk in elkaar verweven.
Hoop dat ik het zo tastbaarder heb gemaakt.
Ach Henri, de ironie niet begrepen.
Het is toch lood om oud ijzer.
Je hebt “Inhoud”, “vormgeving” en “beheer”.
Inhoud opslaan kan als “tekst/bestand” of “database” om het even op welke server.
Vormgeving ook als “tekst/bestand” of “database” om het even op welke server.
Beheer voegt het samen, of van lokaal, cdn’s of webservices elders per API is niet interessant,
Hoe beheer vormgegeven is, schijnt tot de term “headless” te leiden, wat mijns inziens slechts een marketingterm is.
Uiteindelijk moet de stroom lettertjes/pixeltjes toch van een HD/SSD/Cache. via een webserver (apache/nginx) uitgeleverd worden in pakketjes die de browser ontvangt en er een webpagina van maakt om te presenteren of een programma om het te wijzigen.
Als daar wat in verandert is hoor ik het graag.
Die 1 sterren beoordelingen zijn niet van mij overigens, ik geef geen beoordelingen.
Tja, ik weet niet hoe ik het verder uit moet leggen. Maar er zijn wel degelijk extra zaken te benoemen. Headless zelf is niet zo boeiend, het is een aanduiding.
Maar als je een front-end website hebt die geen database onder zich heeft, geen eisen stelt aan de server waarop het moet draaien, geen database connecties heeft (en dus een kleine attack surface), dan kan deze zeer snel zijn, zeer veilig, zeer lichtgewicht. Als je ziet wat voor code WordPress allemaal uitvoert… daarnaast kun je meerdere portal op meerder URL’s deployen met 1 druk op de knop, alleen de aanroep WELKE content opgevraagd moet worden kun je extreem snel en simpel front-ends realiseren.
Het is een andere filosofie, methode en zelfs mindset en ik hou ervan! Ik zie de voordelen, schaalbaarheid, mogelijkheid om kosten te besparen, minder beheer, etc. Uiteraard verplaatst de complexiteit naar andere plekken of wordt het bijvoorbeeld lastiger of meer werk om moeilijkere dingen te doen op het front-end.
Andere scenario’s die ik lastig vind op WordPress en Drupal (naast de vele security patches die halsoverkop geinstalleerd moeten worden, Drupal heeft hier echt wel een paar keer flink last van gehad) is als je een bestaande website wilt vernieuwen. Dus je wilt op de test server elementen toevoegen, aanpassen, etc en deze toepassen op de front-end van productie. Wat een drama is dat!
Als laatste: Ik heb nog *nooit* een goed CMS gezien, wat een drama is dat! Ze zijn ingewikkeld, traag, beperkt, niet gebruiksvriendelijk, belabberde opzet en ga zo maar door. Geen wonder dat ieder software bedrijf uiteindelijk een poging doet zijn eigen CMS te maken die wel goed is. Nu zie je dat met headless CMS-en ontstaan en ik geloof er wel in dat daar goede dingen uit voortkomen…. Moet ik een lijstje opsommen?
“front-end website hebt die geen eisen stelt aan de server”, dat gaat als je alleen HTML/CSS/javascript gebruikt,
Daar heb ik er een paar van gemaakt, ook met oproepen naar “content” van andere servers, geaggregeerd dus.
Dat je minder beheer hebt is niet waar, je moet controleren dat alle URL’s nog geldig zijn.
Ik werk graag met websites/apps die op basis van Smarty gemaakt zijn, dat zorgt voor de presentatie en het gezicht van een site is eenvoudiger te wijzigen.
Ik heb veel CMSsen geprobeerd ben blijven hangen bij CMS Made Simple, bij Sites tot zo 750 pagina’s werkt het naar mijn wensen, het is klein, goed ingericht is het snel en het is open source.