Deze opinie is van een externe deskundige. De inhoud vertegenwoordigt dus niet noodzakelijk het gedachtegoed van de redactie.

GraphQL is het nieuwe 'rest'

Computable Expert

Henri Koppen
Directeur, THINGKS. Expert van Computable voor de topics Digital Transformation, Cloud Computing en Start-ups.

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

"Er is een nieuwe manier om api’s te bouwen die snel opgepikt wordt, namelijk GraphQL"

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. 

x

Om te kunnen beoordelen moet u ingelogd zijn:

Dit artikel delen:

Reacties

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.





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).

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.

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.

Louis Kossen,
De ICT is vooral cyclisch, mijn vraag aangaande GraphQL in de conceptuele architectuur van een ESB heeft Henri beantwoord. De CTO van Thingks heeft nieuwe rietjes gevonden waarbij hij - zoals toegegeven in laatste reactie - wat aanpassingen in autorisaties moest doen. In een Enterprise Architectuur is de schaal waarop dit gedaan moet worden over het algemeen wat groter en complexer. Technologische mogelijkheid om met een bundel rietjes informatie op te vragen uit verschillende (ongekoppelde) bronnen wil nog niet zeggen (privacy-by-design) dat je organisatorisch hiertoe ook geautoriseerd bent. Facebook als voorbeeld spreekt hierin niet tot de verbeelding en maatschappelijke/politieke discussies over transparantie in algoritmen gaat om vertrouwen.

In de discussies heeft de CTO van Thingks zich altijd opportuun getoond met zijn 'developer mind' welke geen rekening hield met de goverance aspecten. Er is daarom altijd een spanningsveld tussen beheer en ontwikkeling want laatste trekt vaak al snel weer verder naar nieuwe groene weiden en laat beheer van eerdere weidegronden aan anderen over, technologische schuld komt vaakt voort uit organisatorische veranderingen.

Interessant artikel, ik kende het nog niet.

Na lezing, vooral van je reacties, krijg ik een beetje het idee dat we terug gaan naar de tijd van de fat clients (het oude client server model).

Ik vond juist het mooie van middleware dat je een abstractielaag kunt plaatsen naar de data en die via een API kunt ontsluiten. De client ontwikkelaar hoeft geen weet te hebben van het datamodel van de database (of databases, want volgens mij gaan we steeds meer naar een hybride oplossing toe). De client ontwikkelaar heeft alleen te maken met de API.

Ik ga komende tijd eens wat van je links lezen, maar naar mijn mening gaan we een stap terug doen als clients kennis moeten hebben van de achterliggende database en het bijbehorende model.

Benno,

Ik heb het misschien niet goed beschreven, maar er is geen sprake van fat clients. GraphQL is een abstractielaag tussen de client (de applicatie c.q. de webpagina) en de database. De client ontwikkelaar heeft alleen maar te maken met de GraphQL API.

Met "Geen weet hebben" weet ik niet precies wat je bedoeld. Het is niet zo dat de ontwikkelaar hoef te weten hoe het onderliggende relationele model (tabellen en de sleutels tussen tabellen) in elkaar steekt. Als je bouwt vanuit een Order ontdek je vanzelf wel dat er aan een order ook een Klant zit en welke eigenschappen deze heeft. Als je bouwt vanuit de Klant zie je vanzelf dat een klant orders heeft, maar bijvoorbeeld ook Betalingen of Retouren. Je kunt juist heel mooi een "Domein" beschrijven.

Om dit even tastbaar te maken. In de database heb je een tabel Orders en Customers. In de tabel Orders is bijvoorbeeld een kolom die status heet. In die status staat "besteld", "geleverd","factureert" of "geannuleerd". In SQL zou je dan doen:

select o.* from orders o where o.customer_id = 123 and status = 'geannuleerd'

In GraphQL zou je dan bijvoorbeeld doen:
{ Orders(Customer: 123) { annuleringen }}

en dan krijg je een lijst met orders van die klant die geannuleerd zijn. In de annuleringen je andere eigenschappen staan dan in bestellingen terwijl ze onder de motorkap allebei uit de tabel Orders komen. Dus heel logisch en intuitief voor de ontwikkelaar.

Maar platgeslagen doet je met GraphQL hetzelfde als wat je ook met SOAP of REST zou willen doen.

Hoop dat deze toelichting wat verduidelijkt.

Henri,
Benno wijst op de reacties, ik ben mogelijk debet aan het idee dat we met GraphQL terug gaan in de tijd wat ik graag wil ontkrachten omdat naar mijn mening de architectuur niet gebaseerd is op een client-server model maar het concept van REST, een software-architectuur voor gedistribueerde systemen zoals het wereldwijde web. Mijn zorgen over de autorisaties hierin heb ik al kenbaar gemaakt, je voorbeeld van een query over de geannuleerde orders is voor de concurrentie namelijk heel interessant. Het delen van kennis kan ook tegen je werken als we kijken naar bedrijfspionage middels arbeidsmobiliteit.

Ik heb er ook even naar gekeken en een korte cursus gedaan. De volgende zaken lijken me interessant:
1) De client bepaald welke data ze ophaalt en hoeveel dus ook
2) Filters worden bepaald en worden ook door client bepaald
Ad 1. Je bent nog wel afhankelijk van het graph model dat je opstelt en hoe makkelijk de verschillende nodes (data entiteiten) zijn te koppelen met de backend systemen. Hiermee kun je mooi voor de client in 1 call data bij elkaar harken waar dit vaak met REST met meerdere resource calls moet. Dus je kunt performance winnen.
Ad 2. Aangezien je met REST custom moet afspreken welke query parameters je allemaal mag gebruiken is er veel afstemming nodig en implementatie wanneer dit verandert. Met GraphQL is een standaard gedefinieerd en krijg je veel out-of-the-box (zoals filtering en pagination).

Ik ben zeer geïnteresseerd naar de ervaringen van mensen hier.

RJH,

Mooie toevoeging en goede observatie.
Mijn ervaring weet je al en wil best een keer een demo geven van productie.

Henri,

bedankt voor je aanvulling. Mijn veronderstelling was inderdaad dat je een soort sql achtige taal had waarbij je direct op de achterliggende DB queries gaat afvuren.

Met "geen weet hebben van de database structuur" bedoel ik dat je dat naar mijn mening los moet trekken in je middleware. Hoe data opgeslagen worden is voor de client helemaal niet relevant, die moet gewoon functionele data krijgen in objecten. Daardoor kun je de verantwoordelijkheid voor bv de database(s) ook los trekken en neerleggen bij de juiste personen. Voor de clients blijft alles gelijk als er bv aan de DB kant wijzigingen zijn.

Ik zal er de komende tijd eens wat meer over gaan lezen. Voorlopig blijft Rest voldoende ;).

Wat mij zeer aanspreekt is de aansluitbaarheid op Python, en daarmee ook de mogelijke koppeling met een 5GL zoals ik deze voorsta: https://www.dt5gl.com/

Net als SQL is GraphQL een declaratieve taal en dus 4GL. Maar binnen 4GL is hier sprake van een evolutie, getuige deze op internet gevonden quote (die mij zeer aanspreekt): GraphQL is SQL for Knowledge, not Data.

In één oplossing heb ik de koppeling met SQL laten zien (Organs-part2.txt), maar dat zou dus net zo goed (en nog veel krachtiger) met GraphQL kunnen!

Ondertussen zou ik nog wel eens een oplossing voor deze challenge met een lowcode of nocode tool willen zien, maar dat nu geheel terzijde.

In ieder geval een leuk geschreven, informatief opiniestuk!

Hi Jack,

Bedankt voor je compliment! Ik weet nog niet of ik klaar ben voor 5GL en zou nog wel een keer een voorbeeld van GraphQL met beslissingstabellen willen zien.

en wij gebruiken o.a. Python icm GraphQL.

Henri, het aardige is dat jij dat voorbeeld veel sneller kan geven dan ik.
Want dat voorbeeld krijg je als je de SQL-query’s in de eerder genoemde oplossing Organs-part2.txt omzet naar GraphQL.

Is een voordeel van GraphQL boven SQL niet ook dat je een hele batterij aan joins uit de meer ingewikkelde SQL-query’s wegwerkt?
Ik heb nog even gezocht naar een SQL to GraphQL converter, maar kon niet snel een handzame vinden.

Het idee van Oudlid om GraphQL in te zetten als een soort van ESB vind ik zo gek nog niet :-)

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.

Uw reactie

LET OP: U bent niet ingelogd. U kunt als gast reageren maar dan wordt uw reactie pas zichtbaar na goedkeuring door de redactie. Om uw reactie direct geplaatst te krijgen moet u eerst rechtsboven inloggen of u registreren

Vul uw naam in
Vult u een geldig e-mailadres in
Vult u een reactie in
Jaarbeurs b.v. gaat zorgvuldig en veilig om met uw persoonsgegevens. Meer informatie over hoe we omgaan met je data lees je in het privacybeleid
Als u een reactie wilt plaatsen moet u akkoord gaan met de voorwaarden

Stuur dit artikel door

Uw naam ontbreekt
Uw e-mailadres ontbreekt
De naam van de ontvanger ontbreekt
Het e-mailadres van de ontvanger ontbreekt

×
×
article 2020-03-03T11:04:00.000Z Henri Koppen
Wilt u dagelijks op de hoogte worden gehouden van het laatste ict-nieuws, achtergronden en opinie?
Abonneer uzelf op onze gratis nieuwsbrief.