Artikelen / 8 minuten leestijd, door Jorn Henkes

Websites ontwikkelen met een headless CMS

In de twaalf jaar dat Jannes & Mannes bestaat, werken we al zeker tien jaar met WordPress. Een handig content management systeem (CMS) waarmee je een website makkelijk vult, beheert en up-to-date houdt. Een groot voordeel van het gebruiken van een CMS is dat de opdrachtgever niet altijd afhankelijk is van ontwikkelaars om de content van de website up-to-date te houden. Voor ontwikkelaars is het soms echter een beperking. Bij een website met CMS heb je namelijk niet de volledige vrijheid om precies zoals je dat zou willen te ontwikkelen. Gelukkig hebben we daar iets op gevonden. De achterkant van de website bouwen we met gebruik van een CMS, maar de voorkant staat hier helemaal los van. Op die manier kunnen zowel opdrachtgever als ontwikkelaar volledig hun eigen invulling geven aan de website. Mooi toch?

Een headless CMS met een ‘losse’ voorkant

We geven het meteen toe; we hebben dit principe niet (helemaal) zelf bedacht. We hebben eigenlijk gedaan waar we altijd al goed in zijn geweest. Van een aantal tools hebben we de beste onderdelen samengebracht, zodat het in onze dagelijkse praktijk optimaal werkt. In de afgelopen twee jaar hebben wij onze werkwijze erop aangepast en het principe verder geperfectioneerd.

Wat we doen is het volgende; we gebruiken WordPress niet meer op de traditionele manier, maar voor twee specifieke doeleinden. Allereerst als content management systeem: de plek waar de klant alle content voor de website kan beheren. Ten tweede doet het CMS dienst als REST API, een gestandaardiseerde tool om alle informatie uit het CMS op te halen, zonder dat er opmaak bij komt kijken. Het draait daarbij dus puur om data. Om de ingevoerde content te kunnen gebruiken in de voorkant van de website, maken we in de voorkant verbinding met de REST API. We halen alleen de benodigde data uit het CMS op. In de voorkant kunnen we daar vervolgens mee doen wat we willen. Het CMS is nu ‘headless’ geworden: de data wordt niet direct voor weergave gebruikt, maar alleen als bron. Die data kunnen wij vervolgens op elke willekeurige plek inzetten.

API

Even een korte uitleg over wat een API precies is. Geen zin in? Skip dan naar het volgende kopje. API is de afkorting van Application Programming Interface. Het is een manier van communiceren tussen twee applicaties. Applicatie 1 dient een verzoek in bij applicatie 2, bijvoorbeeld door een url aan te roepen. In deze url staat aangegeven welke informatie opgevraagd wordt. Applicatie 2 verzamelt de informatie en stuurt het resultaat terug, in een van tevoren vastgesteld, gestructureerd format. Vertalen we dit principe concreet naar WordPress, dan zou je bijvoorbeeld de laatste tien nieuwsberichten uit de website kunnen opvragen. Je dient bijvoorbeeld een verzoek in bij de WordPress website, met de volgende url: example.com/wp-json/wp/v2/posts?per_page=10&order=date&orderby=desc&_fields=title. Als je dat in stukjes knipt, stel je de volgende vraag aan de API.

  • example.com/wp-json/wp/v2 verwijst naar de juiste plek binnen het WordPress CMS.
  • /posts?geeft aan dat je nieuwsberichten wilt (dit kan ook een willekeurig ander post type zijn). Daarna volgen een aantal parameters die de aangeven hoe je de data gepresenteerd wilt hebben.
  • per_page=10 geeft aan dat je 10 berichten wilt zien;
  • order=date geeft aan dat je ze wilt sorteren op volgorde;
  • orderby=desc geeft aan dat je de nieuwste eerst gesorteerd wilt hebben;
  • _fields=title geeft aan dat je alleen de titel van elk bericht wilt zien.

Het resultaat is een lijst van maximaal 10 berichten, mits die er zijn. Als er geen berichten zijn, krijg je een lege reactie terug. Welke parameters je kunt opsturen is gedefinieerd en gedocumenteerd in de WordPress API.

Van ontwerp naar een werkende website

Voor alle websites die we ontwikkelen wordt eerst een ontwerp gemaakt. Aan de hand van het ontwerp ontwikkelen we de visuele weergave – de voorkant van de website – en zorgen ervoor dat je kunt navigeren. In sommige gevallen zorgen we voor animaties in de website. We kunnen de website ontwikkelen binnen WordPress, maar soms is het simpelweg sneller – én leuker – om dit op een andere manier te doen. Die andere manier hebben we gevonden met het framework Nuxt.js.

Nuxt.js

Nuxt.js is een framework dat geschreven is in de programmeertaal Javascript. Het framework bestaat uit een verzameling tools die allemaal weer in Vue.js geschreven zijn. Ook dit is een framework dat bedacht is om te programmeren in Javascript, gecombineerd met de opmaaktalen HTML en CSS. We hadden al ruime ervaring met Vue.js voor andere projecten. Het is een fijne manier om de voorkant van een webapplicatie mee te ontwikkelen. Zo hebben we er bijvoorbeeld het portal voor PeterConnects mee gemaakt.

Voor het ontwikkelen van een publieke website is alleen het gebruik van Vue.js niet voldoende. Het mooie van Nuxt.js is onder andere dat het een extra laag aan Vue.js toevoegt. Hiermee kan een goede paginastructuur opgezet worden. Normaal gesproken wordt Javascript pas uitgevoerd als een webpagina geladen is. Alle inhoud die met Javascript aan de webpagina wordt toegevoegd is dan niet goed door zoekmachines te indexeren. In Nuxt.js is hier iets op gevonden, zodat je én in Javascript kunt programmeren en een goed vindbare website hebt. Bepaald niet onbelangrijk dus.

Zoekmachineoptimalisatie is in de basis van het framework meegenomen. Het is daarnaast heel gemakkelijk uit te breiden met andere Vue.js tools en met tools van eigen makelei. Het allergrootste voordeel is echter dat het ongelofelijk eenvoudig is om een API uit te lezen en de data uit de API te te gebruiken in de code. Hier komen ons framework en het CMS dus weer samen.

Data van verschillende bronnen in een website gebruiken

Het grote voordeel van deze werkwijze is dat de voorkant van de website niet meer gebonden is aan het WordPress CMS. We hebben de vrijheid om meerdere databronnen te gebruiken en we zitten niet vast aan de programmeertaal van de databron. Zolang er een API beschikbaar is, kunnen we de gegevens op een gestandaardiseerde manier uitlezen en naar wens inzetten in de website. Dit hebben we inmiddels voor veel verschillende klanten kunnen doen, met veel verschillende toepassingen.

Voorbeeld case: Paardenarts

Een voorbeeld van een headless CMS is de volledig opnieuw gebouwde website voor Paardenarts. De website bevat een grote hoeveelheid uiteenlopende, zeer specialistische kennis voor paardenhouders, en een finder met een uitgebreide database van paardenartsen in Nederland. Op de website vind je artikelen en nieuwsberichten die we via de REST API uit WordPress halen. Naast het weergeven van de artikelen op de website, moet er ook gericht gezocht kunnen naar informatie. Zoeken gaat via de WordPress REST API niet zo snel, dus hiervoor hebben we ElasticSearch gebruikt. Dit betekent dat we in Nuxt.js zowel informatie uit de WordPress API als de Elastic API halen. Tijdens het bezoek aan de website merk je helemaal niet dat informatie uit verschillende bronnen komt, omdat we de data uit twee bronnen precies zo kunnen structureren, stylen en in de website verwerken als we willen.

Het regent nu óók op de site van Pink Fluffy Unicorns

Een ander voorbeeld van een headless CMS is de website van Pink Fluffy Unicorns. We werken al een tijd voor deze Unicorns uit Nieuwleusen, maar hun website was nog niet zo sprankelend als de naam doet vermoeden. De website was opgezet met een elementenbouwer in WordPress, waardoor de voorkant er goed uitzag. Het beheer was echter erg ingewikkeld. Iets aanpassen naar de wens van de klant, werd al vrij snel een ingewikkeld verhaal, dus dat moest anders. Bovendien had Pink Fluffy Unicorns een extra verzoek aan ons: “Kunnen jullie ervoor zorgen dat de afbeeldingen in de website reageren op het weer?”

Dat konden we zeker. Om te beginnen hebben een geschikte API met weerinformatie gezocht, die het huidige weer op de locatie van de bezoeker ophaalt. In de website gebruiken we die informatie om de juiste afbeelding te tonen. Regent het volgens de weer-API, dan laden we een afbeelding met regen in. Met een losse front-end was het een makkie om dit samen te brengen met de data die de klant in het CMS in kan vullen, die we vervolgens via de REST API kunnen uitlezen.

“What’s in it for me?”

Voor veel websites is deze opzet heel werkbaar. Je website wordt schaalbaar, je bent minder afhankelijk van een CMS en je hebt de mogelijkheid om informatie van meerdere plekken te halen en toch makkelijk en consistent in één website te presenteren. Wat we bovendien nog niet eens besproken hebben is dat deze opzet potentieel heel veel snelheidswinst kan opleveren. Dit is niet alleen goed voor de bezoekerservaring, maar het levert ook winst op bij zoekmachines. Hierover later meer in een ander artikel.

Altijd een headless CMS?

Voor veel sites werken we nu met deze methode, maar we maken ook nog steeds websites waarbij we het CMS en de voorkant in één systeem uitvoeren, helemaal binnen WordPress dus. Waarom? Soms leent deze traditionele opzet zich beter voor de situatie. Denk bijvoorbeeld aan een webshop met WooCommerce, of een website waar gebruikers ook kunnen inloggen en actief deel kunnen nemen aan de ins & outs van de website. Ook voor een blog site is de traditionele opzet heel goed werkbaar. Per website maken we dus de afweging welke opzet het best werkt.

Ben je klaar voor een headless CMS? Neem contact met ons op en we kijken samen wat we voor je kunnen betekenen en hoe we dat in jouw geval het beste kunnen doen.

Jorn Henkes


070 219 2588

Eerdere artikelen