Toen de eerste webapplicaties gebouwd werden, was dat vaak met een webserver die een directe verbinding had met de database. Als daar later een app aan moest worden toegevoegd voor je smartphone moest daar een application programming interface, ofwel api, voor gemaakt worden. Hetzelfde was ook nodig voor integratie met andere systemen omdat je deze geen directe toegang wilt geven tot jouw database.
De api-laag werd vaak als een afterthought toegevoegd en was beperkt in functionaliteit. Dit tijdperk hebben we al een tijdje achter ons gelaten. Waarin een jaar of vijftien geleden nog soap xml werd gebruikt om zo’n api te bouwen, is deze met de komst van smartphones en moderne webapplicaties al snel vervangen met restful api’s. Rest als technologie is overigens ouder dan soap maar dat terzijde. Kort door de bocht bestaat een rest api uit een serie van links zoals deze website ook een link is. Ieder link wijst vaak een resource. Bijvoorbeeld mijnapp.nl/api/customer of mijnapp.nl/api/order. Met de juiste toegang krijg je dan een lijst met customers of orders te zien in json formaat. Json is net als xml maar prettiger om naar te kijken en tegenaan te praten als software ontwikkelaar. Vaak werkt het dan zo als je mijnapp.nl/api/customer/id/123 opvraagt je de customer met ID 123 krijgt. In json- formaat, bijvoorbeeld:
r “id”:123,
“name” : “klant x”,
“total_orders” : 24,
“last_order” : “2020-02-29”
}
Industriestandaard
Rest api’s zijn feitelijk de industriestandaard, soap wordt vooral in legacy en bij corporates gebruikt. Rest api’s kennen ook nadelen. Zoals in iedere architectuur krijg je vroeg laat frictie met de naamgeving en wordt de api doorontwikkeld met functies, maar moet de api natuurlijk wel backwards compatibel blijven. Je krijgt dan bijvoorbeeld nieuwe versie van de api’s met een volgnummer.
Dit zit dan ook weer de snelheid in de weg van doorontwikkeling, of je moet de versies van de applicaties gelijk releasen met de versies van de api’s. Ook zal een rest api altijd hele objecten terugsturen. Het is heel voorspelbaar en altijd compleet, maar vaak ook veel meer dan je nodig hebt, bijvoorbeeld als je alleen maar een zoekfunctie maakt om een klant te selecteren. Daarnaast geldt; als je een pagina vult met informatie moet je meerdere verzoeken naar de api sturen om een compleet beeld te krijgen… Je voelt het aankomen wat ik nu ga schrijven.
Sinds een paar jaar is er een nieuwe manier om api’s te bouwen die snel opgepikt wordt: GraphQL.
GraphQL is ontwikkeld door Facebook en voor het eerst gedeeld met de wereld in 2015. GraphQL is opensource, dat betekent dat het niet meer van Facebook zelf is en de code publiekelijk inzichtelijk. Het is het mooiste wat Facebook ooit heeft voortgebracht, al is ReactJS – een front-end framework – een goede tweede en je ziet ze vaak samen.
GraphQL lost veel problemen op die ik met rest heb. Je hebt nog maar één link waarop je alles kunt opvragen. Je vraagt ook alleen op wat je nodig hebt. Wil je alleen de top vijf grootste customers met hun laatste vijf orders dit jaar zien? Fluitje van een cent. Met één request naar de server haal je direct al je informatie op en je krijgt een voorspelbaar resultaat in json-formaat terug. In principe heb je weinig uitdagingen in backwards compatible en hoef je de release cycles niet meer strikt af te stellen met de front-end developers. Continuous deployment en integration worden hiermee een stuk eenvoudiger. Als developer haal je op wat je nodig hebt en niets meer.
Ook is het eenvoudig om meerdere soorten databronnen op een uniforme manier te ontsluiten. Je kunt relationeel, nosql en zelfs een tekst bestand via één query combineren en opvragen. GraphQL is middleware, je kunt het op allerlei manier aansluiten op Python, NodeJS, .NET, et cetera. Het is in feite een querytaal waarmee je op declaratieve wijze een resultaat op kunt vragen. Met declaratief bedoel ik dat je het gewenste resultaat beschrijft en GraphQL uit laten zoeken hoe deze aan het resultaat komt. Het past hiermee heel goed in het plaatje van microservices en serverless. De standaard tools zoals Graphiql (met een i dus) heb je direct een omgeving waarin je query’s kunt schrijven die je één op één kunt kopiëren en plakken naar je code. Het is net als de rest-technologie taal-onafhankelijk, dus iedereen kan er direct mee aan de slag
Hoe begin je met GraphQL?
Mijn filosofie is altijd al api centrisch geweest. Ons leerplatform was eerst gebaseerd op een rest-architectuur. Dat heeft ons altijd een beetje dwars gezeten. Het remde de doorontwikkeling en voelde meer als een last dan een verlichting. GraphQL klonk erg aantrekkelijk, maar het was ook nieuw en onzeker. Bijna niemand gebruikte het in productie en tegenwoordig is het best risicovol om een lock-in met een framework te krijgen. Je weet nooit of het ineens in de steek gelaten wordt. Wij zijn begonnen om nieuwe aanvullingen via GraphQL te bouwen en zodoende ervaring op te doen. De klik was er bijna direct en vorig jaar hebben we nagenoeg ons hele platform omgeschreven naar GraphQL. Ook omdat GraphQL veel real-time mogelijkheden biedt via websockets en pubsub constructies.
Maar GraphQL kent ook nadelen. Je moet opnieuw nadenken over cache. Er is weinig kennis van GraphQL in de markt. Als externe partijen ook de api willen consumeren betekent dit ook een leercurve of afkeer. Waar rest-api’s extreem schaalbaar gemaakt kunnen worden zul je dit met GraphQL zelf uit moeten vogelen. GraphQL is meer een query language dan een architectuur. Je kunt GraphQL zelfs over een rest-api heenleggen. Ik zou dus GraphQL geen vervanger van rest willen noemen, maar gewoon een alternatieve manier om de tussenlaag te bouwen tussen front-end en back-end. Daarnaast is het zeer developer vriendelijk als je query’s schrijft dat er intellisense in zit. Je ziet direct of de query klopt en kunt hem ook direct testen. Het helpt enorm om sneller te ontwikkelen en of je de front-end nu in een native app doet of de browser maakt niets meer uit. It just works.
Wij zijn in ieder geval volledig over en kijken nooit meer achterom. Ben je cto of werk je met ontwikkelaars? Geef het een keer kans en bedank me later.
Dit is een reactie om in ieder geval mails te krijgen als er een reactie komt.
Als je vragen hebt, stel ze dan hieronder.
Leuk artikel, heb al eens tegen GraphQL zitten aankijken maar weet nog niet zo goed wat ik ervan moet denken. Je schrijft het al aan het eind, GraphQL is geen vervanger van Rest maar een alternatief voor de communicatie tussen front en backend. Dat is wat ik ook denk.
Een van de argumenten die ik hier lees (en op ander plaatsen) dat je in geval van GraphQL nog maar 1 call nodig zou hebben om je resultaat binnen te halen. In plaats van meerdere calls als je Rest zou gebruiken. Ik snap dat niet helemaal, het is toch maar net hoe je je jouw Rest api inricht? Queries verpakt in Rest calls. Zou je het ook bij wijze van spreken met 1 call af kunnen.
Het gaat om die achterkant als ik het zo lees. Het ontsluiten van data uit verschillende bronnen. Dat het dan uit de hoek van Facebook komt is dan wat beter te begrijpen. Wat ik me dan afvraag, als je kiest voor GraphQL hoort daar dan ook niet software aan de achterkant bij? Of word je geacht de backend software voor het combineren van data zelf te schrijven? Of bestaande oplossingen? Apollo zie ik wel eens langskomen. Denk nu, wanneer GraphQL te gebruiken, bij veel verschillende bronnen aan de achterkant met veel verschillende calls, steeds andere data. De kracht zit aan de server kant.
Heel iets anders, jij houdt de ontwikkelingen in de gaten. React komt hier langs, heb zelf ook wel wat naar de javascript frameworks zitten kijken en waar ik nu blij van wordt is Svelte. Moeite waard om een keer naar te kijken (als je het al niet gedaan hebt). Met een hele andere benadering, js code voor het front-end wordt gegenereerd via een compilatie (Svelte compiler) slag in plaats van hele front-end libs die ‘mee’ moeten. Gevolg, minimale hoeveelheid js code en heel snel.
Henri,
Alle zoekopdrachten over GraphQL zijn het eens, het is een zoektaal over API’s heen. Oneerbiedig gezegd is het de zoveelste ‘rapport-generator’ met voornamelijk een consumerend karakter. Leuk voor het idee van ‘datalakes’ waar je met een rietje de informatie uit kunt zuigen maar omgekeerd lijkt het bellen blazen niet mogelijk:
http://spec.graphql.org/draft/
Maar jij bent natuurlijk de expert Henri en je hebt je hele platform al omgeschreven naar GraphQL wat ik nogal opmerkelijk vind gezien de informatie in bovenstaande link.
Hi Louis,
Als je een REST echt als een architectuur aanvliegt. Dus dan heb je geen “Queries verpakt in Rest” 🙂
Daarnaast is zo’n response “fixed”. je krijgt altijd de hele query terug met alle velden. Daarnaast is zo’n API niet zelfbeschrijvend of hard typed. Daarnaast verlies je daarmee al direct de sterke kanten van REST.
En ja, GraphQL zelf doet niets en kan niets, er hoort dus software aan de achterkant bij in de taal die het beste bij je past zoals Apollo.
GraphQL is eigenlijk een query taal waarin je beschrijft welke data je op wilt halen op een eenvoudige dynamische manier. Het is een methode om de koppeling tussen front-end en back-end soepeler te laten verlopen.
Svelte zijdelings naar gekeken, maar we hebben nu net een refactor gehad naar TypeScript, dus denk niet dat ik hier snel iets mee ga doen, maar hou het wel in de gaten. Waar we wel echt een reden voor zoeken om te gaan gebruiken is Elm : https://elm-lang.org/
Maarja JS land is net een ghetto. De ene dag is iets hot en de volgende dag word het verlaten. Ik wissel tussen JS Fatigue en JS fatigue fatigue (hahaha).
Oudlid, waarom ga je niet gewoon naar https://graphql.org/ en bekijk de voorbeelden.
Hoe je het wilt noemen vind ik niet zo boeiend en het is niet alleen ophalen maar ook schrijven (CRUD).
En wij gebruiken het zeer zeker niet om te query-en op datalakes of als rapport generator, maar gewoon op relationele en nosql databronnen.
We passen het in feite toe zoals je vroeger een connection tussen een client en een database hebt.. je vraagt data op en schrijft data terug.
En je bent vrij om het te testen, ik laat je graag meekijken in de console waarin je zowel de query’s als de responses ziet.
Ik snap je reactie daarom ook niet helemaal.
Henri,
Zou je, uitgaande van het concept van een Enterprise Service Bus (met SOAP, REST enz.) duidelijk kunnen maken wat er wezenlijk anders is met GraphQL dan vroeger? Ik zie op dit moment namelijk alleen maar een extra tool die op basis van het één-voor-één concept van een rietje de vraagstelling van een query vereenvoudigt. En dat gezegd hebbend ben ik verder gaan kijken over CRUD, de uitleg op de onderstaande link hierover is duidelijk:
https://medium.com/@JeffLombardJr/when-and-why-to-use-graphql-24f6bce4839d
Complexiteit verminderen door abstractie is fijn voor een ontwikkelaar zoals jij maar ik ben geïnteresseerd in de architectuur want hier geldt, hoe complexer hoe risicovoller. En een plaatje hierin zegt meer dan duizend woorden, ik denk dat het plaatje over GraphQL Proxy in de bovenstaande link een beeld geeft over je oplossing want zoals jezelf al zegt is het net als vroeger alleen met een andere hamer.
Oudlid, ik zal het toelichten, maar ik weet niet of het in een reactie past die korter is dan het artikel zelf. Eerst even wat house cleaning:
– de context waarin ik schrijf is niet enterprise. Ik schrijf dat wij een digitaal leerplatform hebben en dat we erg blij zijn met onze keuze om GraphQL te gebruiken en afscheid te nemen van REST.
– Ik zou GraphQL niet gebruiken als een Enterprise Service Bus en niet met een ESB. Als ik aan ESB denk, denk ik aan het BizTalk van vroeger. Als ik aan BizTalk denk, moet ik kokhalzen. Alleen masochisten houden van BizTalk en alleen sadisten kiezen ervoor.
– Ik heb een sterke afkeer tegen zowel XML als OData en daarmee ook tegen SOAP, hoewel het concept van SOAP me meer aansprak dan REST. REST is uiteindelijk superkrachtig, maar ook lomp en omslachtig.
– Door mijn SQL (en .NET) achtergrond heb ik een voorkeur voor declarative data opvragen en was ik ook niet alleen goed in LINQ maar ook fan al blijft SQL favoriet.
– GraphQL voelt als een evolutie op SQL maar dan verpakt in een formaat die heel natuurlijk aansluit op de taal van het web: JavaScript.
Waar ik in jou ogen hamers zie, zie jij rietjes. Maar maak niet de fout om GraphQL als een rietje te zien. Facebook gebruikt GraphQL in productie voor Facebook. Het is dus krachtig, schaalbaar en robuust te maken.
Ik vermijd ook complexiteit en vandaar dat we dominant op GraphQL over zijn, we gaan dit ook gebruiken in alle future development.
Waarin GraphQL schittert is juist zijn uniformiteit en eenvoud. Je kunt sneller ontwikkelen wat een besparing is, maar je loopt ook minder snel tegen technische schuld aan, wat ook een besparing is. Je kunt veel breder en sneller vernieuwing ontsluiten naar je front-end ontwikkelaars en hebt een interessantere life-cycle,mits goed toegepast. Door de hard-typed query’s heb je ook een natuurlijkere manier om het datamodel te ontdekken. Als je een Customer zit en children toe wil voegen en je tikt “ord” in en je ziet orders verschijnen, dan voelt dat heel intuitief aan. Wij gebruiken GraphQL dus niet of zo min mogelijk als proxy. Client — GraphQL — Database. Waarin GraphQL dus de API is en niet een abstracte “wrapper” om de API heen. Dat moet je ook niet willen want is per definitie technische schuld. Ik geef dus nadrukkelijk niet het advies om GraphQL over je bestaande zooi heen te zetten met als reden om developers te pleasen.
Dus JA GraphQL is een hamer… een manier net als dat je SOAP, REST of ESB in zou kunnen zetten, maar daar is niets mis mee. Je kan het ook op andere manieren gebruiken zoals de proxy, maar daar ben ik geen voorstander van.
Dus nogmaals. GraphQL is voor ons een manier om data uit onze database te ontsluiten op een uniform en prettige manier die in mijn ogen toekomst vast is. Het is onze keuze voor innovatie en tot nu toe zijn we zeer positief verrast. We hebben ook een tool gebouwd op Erlang en Websockets en daar past GraphQL ook prima tussen om de realtime communicatie te doen.
En developers hebben een lange geschiedenis van kennis delen. Dit is mijn manier om deze kennis te delen. Ik heb er geen ander belang bij dan dat ik het leuk vind om mensen te helpen en daar voldoening uit haal. Net als dat ik veel geschreven heb over cloud computing, maar geen cloud computing consultancy lever, slecht bij opinie en bevindingen.
Ik kan met liefde een presentatie met live voorbeelden geven. Overigens ben ik niet de developer.. Ik ben de product owner slash CTO.
Henri,
Ik raak blijkbaar een snaar als ik kijk naar je reactie, de metafoor van nietjes versus spijkers is dan ook een leuke als we kijken naar een ‘decoupled’ architectuur van eigenaarschap aangaande de informatie die je ontsluit want oude autorisatie model van RBAC – zoals bij databases – is met het model van Facebook achterhaald. Ik kan een presentatie over de spijkers en het kruis geven want de keuze van CTO Thingks is niet zo heel toekomstvast als we kijken naar je opinies en bevindingen.
Henri, nog wat zitten kijken naar de GraphQL en het sterkste punt vind ik de leesbaarheid. Het sluit precies in bij wat je wil, maar blijf vinden ook vinden dat de argumenten die ik her en derl lees (overfetching) niet geheel overtuigend zijn omdat ik denk, dat zou ook binnen de bestaande REST met een paar ongelukkige argumenten ook kunnen. Leesbaarheid en standaard vind ik een hele sterke. Maar ga er zeker nog eens verder in duiken. Vind het wel mooi.
Dat is me inderdaat wat die Javascript wereld, chaotisch, heel erg veel en intimiderend. Soms mooi, soms slecht. Javascript vind ik al geen gemakkelijke taal/omgeving, maar het ene is er nog niet of het andere dient zich alweer aan. Zoals bijvoorbeeld met die frameworks. Maar ik denk ook, dat je er niet ontkomt om in de gaten te houden wat er speelt en je moet niet te bang moet zijn. ZOals bijvoorbeeld, heb me afgelopen tijd verdiept in Vue.js, mooi framework, maar ik zag ook dat er als het even tegenzit bergen js code meegaan. Het komt de performance niet altijd ten goede en daarom voor dit moment enthousiast over Svelte. Geniaal natuurlijk, compileren! Maar ja wat is het morgen? De karavaan trekt voort zeker in Javascript land.
Elm misschien, heb er even kort naar zitten kijken. Weer een taal is het eerste wat ik dacht. Om web frontends mee te genereren zag ik. Het is een kwestie van keuzes maken, in deze veelheid, maar ik laat hem nog even links liggen. Eerst maar eens GraphQL.
@OudLid Weinig is toekomstvast. Zeker in computerland. Al denk ik ook het is veel van hetzelfde en net even anders en je hebt allemaal al een keer eerder gezien in iets andere vorm. Hoewel ik zeer en zeer conservatief over ICT ben (leve legacy, ga niet repareren wat niet stuk is) ontkom je niet aan ontwikkelingen. In ieder geval met dat malle web.
Hi Louis, haha, je beleving over Javascript is spot on!
Dat over en underfetching vind ik ook niet per se heel interessant. Misschien wel als je echt op grote schaal opereert en iedere byte telt. Ik zie in GraphQL meer dan leesbaarheid en standaard, dat is iets waar je zelf maar iets van moet vinden. Leercurve in het begin is nog wel wat steil, ook moesten we best nog wat aanpassen voor autorisatie en hoe we met sessies omgaan.
Als je tegen praktische uitdagingen loopt kan ik je koppelen aan een developer die je kan helpen. Wij zoeken overigens nog ontwikkelaars die van deze uitdagingen houden en hiermee aan de slag willen. We hebben een leuk team, zijn gek op innovatie en pionieren en geloven in de developer mind.