Headless Drupal. Waarom & Hoe Een Restful Api In Drupal?

Wij zijn momenteel bezig met een mooi ‘Headless’ project. Klinkt eng, 'zonder hoofd', maar wij worden hier als Drupal backend ontwikkelaars erg blij van.

Eerder blogde ik over Drupal web services: het bouwen van een (RESTful) API op Drupal. Dit staat ook wel bekend als Headless Drupal. Het fenomeen bestaat al langere tijd maar de afgelopen maanden lijkt Headless Drupal exponentieel actiever te worden. Ik zie wereldwijd veel code en blogs binnen deze context verschijnen.

Vandaar dacht ik: laten we hier eens een blog aan wagen:

Wat is Headless Drupal

Ok, dus wat is er anders aan Headless Drupal dan aan standaard ‘vanilla’ Drupal? Vanuit de website bezoeker gezien: die maakt niet direct verbinding met Drupal, maar met een frontend Javascript framework als KnockoutJS of AngularJS. De website bezoeker ziet dus niet een gegenereerd Drupal theme (the head), die wordt niet gebruikt: headless.

Drupal wordt in dit geval alleen gebruikt als backend content management systeem, dat uitgelezen wordt door een frontend Javascript framework, of mobiele App of andere 3rd party applicatie. Het Drupal backend is dus exact zoals je het kent, maar het frontend is geheel niet-Drupal.

Data uitwisseling vind bijna altijd plaats middels JSON.

Waarom worden wij blij van Headless Drupal

De Drupal installatie is makkelijker in onderhoud.
Drupal is eenvoudiger schaalbaar.
Je kunt makkelijker samenwerken met verschillende teams. Bijvoorbeeld: Team Backend, Team Web front-end, Team iOS App en Team Android App. Zij kunnen relatief makkelijk los van elkaar werken, doordat de Apps los staan van Drupal.
Performance
Meer ‘future proof’

Manifesto

Enkele vooraanstaande Drupal community members hebben recentelijk een manifesto geschreven, waarin 4 doelen:

“We willen dat Drupal het preferred back-end content management systeem wordt voor designers en front-end ontwikkelaars.”
“Wij geloven dat Drupal’s kracht in het vermogen en flexibiliteit van zijn back-end ligt; haar primaire waarde voor de gebruikers is het vermogen om complexe content modellen te ontwikkelen.”
“Wij geloven dat de client-side front-end frameworks de toekomst van het web.”
“Het is van cruciaal belang voor Drupal om primair services oriented te zijn, niet primair HTML georiënteerd, of de dreiging irrelevant te worden.”

Uit dit manifesto blijkt hoe belangrijk Headless Drupal lijkt te worden.

Hoe Headless Drupal

Om Drupal koploos te maken, zul je een (RESTful) API op Drupal moeten bouwen. Data uitwisseling wordt in de meeste gevallen gedaan met behulp van JSON objecten, deze zijn namelijk het meest universeel. Elke zichzelf respecterende applicatie kan omgaan met een JSON georiënteerde API. Via deze JSON objecten kan data uitgewisseld worden: Drupal kan gewenste data uitserveren naar de app, en een third party app kan data naar Drupal toe schieten.

Autorisatie, validatie, workflows, content management etc worden hierin afgevangen door Drupal: het back-end werkpaard.

Als je eenmaal de Drupal RESTful API hebt staan dan kunnen dus mobiele apps, front-end frameworks en third party applicaties daar gebruik van maken.

Headless Drupal 6

Drupal 6 gaat richting het einde van zijn leven (R.I.P.). Er zijn geen kant-en-klare modules (zo ver ik weet) die gewenste RESTful API voor je genereren. Ik zou hier ook niet in investeren, gezien Drupal 6 niet meer wordt ondersteunt zodra Drupal 8 gereed is.

Headless Drupal 7

De Drupal 7 core kent standaard geen RESTful API, maar deze is goed op te zetten met behulp van modules zoals: Services, RestWS of Restful. Beide hebben voor- en nadelen, hierover heb ik eerder geblogd.

Ter vergelijking van deze drie is deze podcast van Lullabot interessant.

Headless Drupal 8

Drupal 8 kent out-of-the-box een RESTful API. Je bent dus voor groot deel gedekt als je de Drupal 8 core installeert. Daarbovenop zullen de bouwers van de Restful module extra tools bouwen, die de Drupal core niet heeft, zoals de OPTIONS call. Ook dit kan je terugluisteren in eerder genoemde podcast van Lullabot

Drupal API Documentatie

Je API is zo goed als je API documentatie: als niemand weet hoe jouw API gebruikt dient te worden, dan kan er weinig mee gedaan worden. Publiceer dus goede documentatie van jouw Drupal API.

Nadelen Headless Drupal

Vooraanstaand Drupal community member Jeff Eaton Tweette:

"Completely decoupling Drupal, right now, comes with drawbacks some projects may not be able to accept. Layout control by editors is much harder. UI localization can’t rely on Drupal, and is harder for admins to tweak w/o front end work. And if the requests aren’t batched effectively, it can incur lots of expensive roundtrips/bootstraps.”

Jared Ponchot antwoordde:

"It's also worth noting that complete decoupling favors a design system that values complete tailoring over flexibility. Ongoing evolution of content requires front-end focused teams also involved in accounting for resulting evolution in presentation."

Bron

Headless is niet alleen maar glorie halleluja, het kent ook uitdagingen. Voor elke uitdaging beschrijven we hieronder een oplossing.

HTML ten behoeve van SEO: zoekmachines kunnen (nog) niet goed JS uitvoeren.
UI localization:
Minder controle op layout door site builders.
Oppassen dat je geen onnodige, ongeziene overhead in Drupal veroorzaakt

1. HTML ten behoeve van SEO

De uitdaging:

Een zoekmachine kan een website die leunt op client-side JS (nog) niet goed indexeren. Dit komt doordat een zoekmachine een robot is en geen webbrowser (client) is welke JS uit kan voeren. Ik vermoed dat dit een van de redenen is waarom Google zijn ‘In Cache’ functie heeft verwijderd enkele jaren geleden. Ze kunnen de layout van websites niet goed meer cachen door al het JS geweld van tegenwoordig.

Enkele oplossingen:

Een isomorphic JavasScript: http://isomorphic.net. Dit zijn JS-frameworks die zowel front-end als back-end kunnen draaien. Nadeel is wel dat je nóg een extra library moet implementeren en onderhouden.

https://prerender.io Maar dit is een betaalde dienst en zal achterhaald zijn als zoekmachines als Google straks wél websites met client-side JS kunnen indexeren. Hier ben ik dus absoluut geen voorstander van.

Een oplossing in Drupal

Wij hebben dit opgelost in Drupal door het initieel laden van een default theme, wat 100% html zonder css is, opgemaakt conform schema.org. KnockoutJS wordt vervolgens aangeroepen, die zal als eerste alle HTML weggooien en daarna zijn magic doen.

Wil je code hiervan inzien, laat het even weten.

2. Drupal meertalige websites: user Interface meertaligheid

De uitdaging:

Ook wel ‘UI localization’ genoemd. Bij een standaard meertalige Drupal website worden interface teksten aanroepen en via het Drupal theme geïndexeerd. Waarna de teksten vertaalbaar zijn in het Drupal backend. Omdat er in het geval van Headless geen Drupal theme geladen wordt, worden teksten dus niet geïndexeerd en kunnen ze niet vertaald worden in het Drupal backend. Tevens is er geen standaard oplossing voor, ook al zouden de teksten wel geïndexeerd en vertaald kunnen worden in het backend.

Een oplossing in Drupal

In ons huidige headless project hebben wij dit als volgt opgelost in het Drupal backend:

We hebben een custom back-end formulier gebouwd waar een JSON object met te vertalen strings in opgenomen zijn.
Nadat deze geüpload wordt, zorgen we ervoor dat deze strings op de juiste manier langs de Drupal API gaan, zodat Drupal deze strings correct indexeert t.b.v. het vertalen ervan.
Daarna kunnen de strings vertaald worden middels de standaard backend vertaal interface (admin/config/regional/translate/translate)
Uitserveren van de vertaalde strings naar het front-end framework gaat via de API. Het front-end framework zal vervolgens deze vertalingen op de juiste manier moeten ‘mappen’.

Wil je hier code van inzien, laat het even weten.

3. Minder flexibiliteit voor site builders

Drupal mét head biedt standaard veel tools voor site builder om een site in elkaar te klikken. Hierin zijn ook vele extra modules waarmee de layout, zonder programmeren, bepaald kan worden.

Wanneer je headless gaat kun je die tools niet gebruiken. Je moet een Drupal developer zijn, wil je headless gaan.

Omdat wij altijd bouwen conform een gespecificeerd Functioneel Ontwerp (FO) en designs, hebben wij hier geen last van: we bouwen exact wat er nodig is. Óok de gewenste beschreven flexibiliteit in pagina opmaak. In een headless Drupal project zul je gewenste opmaak flexibiliteit moeten programmeren, je kunt het niet configureren.

4. Onnodige, ongeziene overhead

Als je niet goed oppast, kan er veel overhead veroorzaakt worden en content onbedoeld publiekelijk staan. Dit komt doordat er Drupal functies aangeroepen kunnen worden die niet nodig zijn. Dit kan voornamelijk gebeuren als je gebruik maakt van de Services of RestWS module: na installatie genereren die meteen endpoints, waar direct data uitgeserveerd kan worden.

De Restful module heeft dit niet: daarin wordt alleen gepubliceerd wat jij in je code bepaald.

Testen van je Drupal API

Er zijn veel developer tools beschikbaar, die hoeven niet specifiek voor Drupal te zijn (een REStful API is namelijk universeel). Wij gebruik hier Chrome extentie Postman voor. Hiermee kan je simulaties van de externe ‘calls’ uitvoeren, als REST client zijnde. Die calls kunnen komen van een front-end framework of een andere externe applicatie. Op deze manier kan je de RESTful API (automatisch) testen.