Alles wat ik heb geleerd tijdens het bouwen van een headless site

Voor de ontwikkeling van deze website heb ik een Drupal 8 backend ingezet met een Gatsby React frontend. Ik heb in eerste instantie JSONAPI gebruikt voor het ontsluiten van mijn website en in een later stadium ben ik de GraphQL module gaan gebruiken. Er zitten wat subtiele verschillen tussen de twee modules, waarbij elk hun voor en nadelen hebben.

JSONAPI vs GraphQL

JSONAPI gaat wat minder goed om met meertaligheid, waar GraphQL weer beter werkt. Daarentegen biedt de JSONAPI out of the box wel meer mogelijkheden en is dat bij GraphQL wat meer werk. De GraphQL queries die je kunt gebruiken binnen de React frontend verschillen ook nogal qua structuur. JSONAPI heeft bijv. allNodeArticle waar je gelijk alles van het type Article kan ophalen terwijl de GraphQL module met nodeQuery{} werkt, waar je zelf de filters e.d. moet opgeven.

Al met al doen de twee niet veel voor elkaar onder en is het vooral op het gebied van meertaligheid waar het verschil wordt gemaakt.

Endpoint

De endpoint biedt standaard alles wat anonieme gebruikers mogen. Dat is (op zich) logisch, maar als je bijv. menustructuren of webforms wilt overhevelen is dat niet handig. Je kunt er voor kiezen om meer rechten uit te delen aan anonieme gebruikers of om je op een of andere wijze te authenticeren. Dit laatste kan met de key_auth module waar je een key kunt koppelen aan een gebruiker. Deze key geef je op in de header en voilla: toegang.

CORS headers

Webform heeft standaard een webform node module in zich, wat het makkelijker maakt om een webform te koppelen aan een node. Vanuit Gatsby wordt de node opgehaald en in een Webform component geplaatst. Daar haal ik los de webform op (via webform_jsonschema) en verwerk deze verder. Echter lukte het in eerste instantie niet om het formulier op te halen door de foutmelding "Reason: CORS header 'Access-Control-Allow-Origin' missing". Oplossing is door default.services.yml te kopiëren naar services.yml en (onderin) de CORS configuratie te activeren. Deze stel je in, cache legen en weer een probleem minder.

It's not you, it's me

Op het moment van live-gang (eerder pre-live-gang) heb ik de backend online gezet en de frontend getest tegen de productie-backend. Dit zorgde voor wat problemen, vooral met de afbeeldingen. Het grootste probleem was dat ik geen localFile queries kon uitvoeren. Om een reden, waar ik een aantal dagen op heb vastgezeten, kreeg ik foutmeldingen ("Cannot query localFile on type file__file"). Achteraf bleek het probleem te zijn dat de gatsby build de afbeeldingen niet kon overhalen door een probleem aan de backend-zijde. In https://backend.web-beest.nl/sites/default/files wordt een .htaccess bestand gegenereerd, die conflicteerde met de server configuratie. Hierdoor werd het bestand niet geserveerd. Het .htaccess bestand aangepast en de build werkt weer. Eigenlijk logisch dat wanneer het lokaal wel werkt en remote niet, dat het probleem dan waarschijnlijk aan de remote ligt en niet aan de code. Of het probleem zit tussen het toetsenbord en de stoel.