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.
Jack,
Zoals gezegd ben ik geen ontwikkelaar en zit niet zo diep in GraphQL maar ik zie het conceptueel als een soort van ESB, een software architectuur om net zoals met SOA op een generieke manier data uit verschillende bronnen te kunnen halen middels micro services. Vanuit een conceptueel architectuur denken zitten mijn zorgpunten dan ook in het authenticatie en autorisatie model, dat iets technisch kan wil niet zeggen dat het organisatorisch wenselijk is. Helaas toont Henri zich hierin opportuun zoals altijd terwijl ik alleen maar wees op het juist componeren van een informatie-flow, want waar je de inner/outer joins van datasynthese doet gaat om de simpele vraag of je de data naar de gebruiker brengt of dat je de gebruiker naar de data brengt.
Het kassa-probleem binnen SOA architecturen gaat niet om 5GL talen die door de mensen makkelijk te begrijpen zijn maar om machine gegeneerde data. In mijn vrije tijd ben ik aan het experimenteren met de IoT oplossingen die er zijn en lang leve Raspberry Pi hoewel mijn oude RPI2PLC oplossing met Piface GPIO nu wat tekortkomingen kent in het I/O path van veilige draadloze verbindingen. Maar dit zijn mijn tekortkomingen omdat ik achterop geraakt ben in het up-to-date houden van alle drivers, open source is fantastisch maar wel arbeidsintensief.
Kennis delen is leuk maar zolang ik de rekeningen er niet mee kan betalen is de keus makkelijk, mensen die me kennen weten dat ik onbezoldigd teveel doe als vrijwilliger. De filosofie van kennis- versus arbeidsintensief gaat maatschappelijk uiteindelijk om de (onder)buik die gevoed moet worden. Betreffende ideeën heb ik te weinig tijd want uiteindelijk moet de kachel thuis blijven branden en zit ik dus zoals vele ontwikkelaars in het open source domein in dezelfde spagaat.
Hi Jack,
GraphQL kun je inderdaad als ESB inzetten, maar je krijgt dan wel een extra laag, die aan de ene kant uniformiteit biedt, maar ook de complexiteit verhoogt. Het kan onverwachte performance issues geven, of als er iets aan de onderliggende services verandert moet GraphQL ook mee.Ik raad het af of iemand moet heel goed weten waar deze aan begint. Ik pas het in ieder geval niet toe.
GraphQL is ook geen intelligentielaag. Het lost niets magisch op. Je kunt er JOINS mee wegwerken aan de vraagkant, waarmee de complexiteit wat meer naar de server kant verschuift. Of je kunt wat herstructureren. Maar ook hier geldt: Take good care. Als de relationele kant teveel afwijkt of als de GraphQL teveel “verbergt” introduceer je gewoon weer nieuwe rampen. Ingewikkelde zaken blijven gewoon ingewikkeld.
Daarnaast is jouw organen voorbeeld een “getrapte” logica. Je kunt deze wel voor GraphQL in elkaar drukken zodat het aan de voorkant lijkt alsof je een vraag kunt stellen en direct antwoord krijgt, maar toekomstige aanpassingen kunnen dan best pittig te verwerken zijn en we weten dat systemen eigenlijk nooit stil staan. Het voordeel van de onderliggende SQL query’s is dat je de logica makkelijk kan doorgronden. Of als er een onverwachte uitkomst uit komt je sneller uitvind waar het probleem in zit.
Stel dat iemand een GraphQL vraag stelt en een onverwachte uitkomst krijgt en daarover een vraag stelt.. dan is dat best even puzzelen voor een oplossing terwijl je in jouw elegante stappenplan al snel ziet in welke stap wat gebeurd.
Je kunt met GraphQL inderdaad het vragen stellen eenvoudiger maken, maar er moet nog steeds intelligentie in voordat dit zo werkt. Ik zie overigens ook niet hoe je dit low-code, no-code op zou kunnen lossen. Als je dat kan ben je echt klaar om 5GL als taal te ontwikkelen…
Henri,
Helaas kennen veel organisaties niet de ‘greenfield’ van cyclische vervangingen en veelal is er dan ook sprake van een toevoeging. Dit geldt niet alleen voor ‘enterprise’ organisaties als we kijken naar de wijze waarop een nieuwe software architectuur geïntroduceerd wordt en de infrastructuur afgeschreven.
De vereenvoudiging van de communicatie met de ‘beeldtaal’ van pictogrammen en iconen is een oplossing die m.i. dichtbij het idee van no-code komen. Idee van een object-georiënteerde visuele programmeertaal zoals Scratch is hier een voorbeeld van. En het idee van een ESB kent in een IoT architectuur m.i. een evenknie met het idee van de ‘eventbus’ als we kijken naar de wijze waarop modulaire bindings met alle ’things’ gedaan worden. Natuurlijk zit onder de motorkap een zeker mate van complexiteit maar niet iedere automobilist is een monteur. De no-code van een visueel dashboard gaat om de ontwikkeling van de UI, eye-candy van beeldtaal in de rapportgeneratoren gaat niet om de wijze van ophalen maar om de manier van presenteren.