Back end

REST vs. GraphQL

De klassieke manier van het bouwen van websites is dat de HTML vanaf de server naar de client wordt gestuurd en als er iets moet veranderen op de site wordt de pagina opnieuw geladen met daarin de aanpassingen. Ook bij het versturen van formulieren wordt hierna de pagina opnieuw geladen.

Soms is het niet nodig om de pagina opnieuw te laden wanneer er aanpassingen worden gedaan. Om een _page refresh _te voorkomen wordt de data via AJAX (Asynchronous Javascript And XML) ingeladen. Hiermee kan data opgevraagd of verstuurd worden zonder dat de pagina herlaadt. Dit zorgt voor een prettigere interactie voor de gebruiker.

Met de komst van frameworks als React en Angular werd het mogelijk om de HTML van een website in zijn volledigheid in de browser te renderen, in plaats van dat de HTML op de server gerenderd werd. Applicaties gebouwd in een framework (React, Angular etc.) zij volledig in JavaScript gebouwd en worden gerenderd in de browser van de gebruiker. Hiervoor moet ook de data apart van een server worden opgevraagd via AJAX. De meest gebruikte architectuur hiervoor is REST API (Representational State Transfer). Als er in deze architectuur alle posts opgevraagd worden, gebeurt dat via de url site.com/api/posts. Wanneer je een specifieke post wordt opgevraagd, gebeurt dat via de URL site.com/api/posts/{id} , waarin id de specifieke post identificeert.

Een probleem bij REST is dat wanneer een specifieke post opvraagt, je álle data van van de post krijgt. Bij bijvoorbeeld een overzicht met een titel en afbeelding van de post is niet alle data nodig, maar alleen de titel en de afbeelding. Hiervoor zijn oplossingen in REST, bijvoorbeeld door aan te geven welke data je wilt via parameters in de URL. Een betere oplossing hiervoor is het gebruiken van GraphQL in plaats van REST. Bij GraphQL geef je expliciet aan welke data je wilt ontvangen. Hierdoor wordt er nooit te veel of te weinig data aangevraagd. Een query van GraphQL zou er als volgt uit kunnen zien:

De applicatie die ik ga maken in deze opdracht zou veel baat hebben bij GraphQL. In bijvoorbeeld het overzicht van schermen hoeven nog niet alle componenten ingeladen te worden, maar bij het detailscherm hiervan wel, dit kan ideaal worden opgelost door GraphQL. Om deze reden heb ik ervoor gekozen om GraphQL te gebruiken.

SQL vs. NoSQL

NoSQL

Toen ik begon met het bouwen van het eerste prototype begon ik met het bouwen van een database met mongoDB en Mongoose. Mongoose maakt het makkelijk om schema's, validatie en relaties toe te voegen aan een mongoDB app.

De bovenstaande relaties moeten aangegeven worden en de logica voor het aanmaken, verwijderen en verplaatsen hiervan moet allemaal zelf geschreven worden. Toen ik de mogelijkheid om variaties aan te maken wilde toevoegen aan de applicatie, kwam ik erachter dat het te ingewikkeld en foutgevoelig werd. Alle business logica die erbij kwam kijken was niet geschikt om te gebruiken met mongoDB.

MySQL

Nadat ik besloten had geen NoSQL database meer te gebruiken, heb ik onderzoek gedaan naar overige opties. Ik mijn app gebruik ik Apollo, een graphQL implementatie. Graphcool heeft Yoga gemaakt, een server die het makkelijk maakt om een Apollo server op te zetten. Ook heeft Graphcool Prisma gemaakt, een laag voor over een MySQL database die een API genereert die weer te gebruiken is met Yoga. Zo wordt er doormiddel van een datamodel geschreven in GraphQL syntax een MySQL database gegenereerd. Hieronder een visualisatie hiervan: