De toekomst van API’s

Al van GraphQL gehoord? Laat ik het maar gewoon zeggen: dit is hoe API’s altijd hadden moeten werken. Zo overtuigd ben ik sinds ik vorige week in San Francisco bij de GraphQL Summit ben geweest. Die werd georganiseerd door Meteor Development Group (MDG), die je misschien herkent van Meteor, waar we al langer mee werken.

Omdat Meteor in principe altijd gebruik maakt van MongoDB als database, is MDG al een poosje op zoek naar een oplossing om data tussen server en client uit te wisselen zonder die afhankelijkheid op MongoDB. Dan zou je een willekeurige database kunnen gebruiken, en je Meteor app langzaam in kunnen faseren in plaats van alles in één keer te moeten omschrijven. Ze zijn uitgekomen op GraphQL, een nieuwe technologie die van oorsprong bij Facebook is ontwikkeld om de newsfeed performant te krijgen op mobiel.

In het kort (omdat je het veel beter gewoon kunt nalezen op de officiële site): met GraphQL stuur je vanaf de client 1 request voor alle data die je nodig hebt, en je geeft daarbij aan in welke structuur die terug moeten komen. Je request wordt gevalideerd door een schema, en is dus typed. Je krijgt daardoor altijd precies terug waar je om vroeg. Aan de back-end verandert er ook een hoop, want hoe GraphQL zo’n API request parset, maakt het leven van de server-side developer ook veel comfortabeler. Je implementeert nu gewoon één voor één de zogeheten resolvers per veld. Die kunnen bijvoorbeeld iets uit geheugen, een database, of een andere API halen. De client hoeft er niks van af te weten.

De summit bestond uit een aantal talks, waaronder een keynote van Geoff, de CEO van MDG, waarin hij uitlegde waarom ze in GraphQL geloven, vertelde over hun nieuwe tooling Apollo, en aankondigde dat die nu productieklaar is. Ze kondigden ook hun nieuwste product aan, Apollo Optics, waarmee je inzicht in je GraphQL API kunt krijgen en zodoende bijvoorbeeld de performance ervan in de gaten kunt houden. We hebben bij Q deze zomer gebruik gemaakt van Apollo en Meteor voor een project voor een klant, en dat beviel, dus we gaan er vast wel mee door.

Verder waren er talks van grote techbedrijven, waarmee ze duidelijk willen maken dat dit veel breder gedragen wordt. Het doet me een beetje denken aan hoe React opeens out of nowhere oppopte en meteen veel support kreeg. Zo bestonden de sprekers bijvoorbeeld uit o.a. Coursera, Google, Shopify, Github en Facebook. De aanpak was een beetje dat de meeste mensen wel iets van GraphQL afwisten, dus dat ze niet de basics gingen uitleggen, maar vooral vertelden in welke valkuilen ze zijn gestapt, welke overwegingen ze hadden, en hoe het beviel om hun architectuur om te gooien naar GraphQL toe.

Eén punt die meerdere keren gemaakt werd is dat je met GraphQL nooit meer versieproblemen gaat hebben. De conventie is daar namelijk om geen versies te hebben, maar velden te deprecaten. Vervolgens kun je, door de algehele architectuur van GraphQL, later makkelijk observeren welke resolvers wel en niet meer worden aangeroepen. Is er een resolver die echt niet meer wordt gebruikt door clients? Dan kun je’m gewoon uit het schema halen.

Wat dit overigens ook doet is zorgen dat je van tevoren heel goed moet nadenken over je schema. Je kunt niet zomaar yolo een API opzetten en lekker procrastineren, dan ga je problemen krijgen. Facebook en cohorten raden dus aan om er een discussie in het team van te maken, dus zowel met backend architecten alsmede de frontenders. Er was bij de conferentie een vraag over wie de “owner” is van de API, maar verschillende teams gaan daar blijkbaar verschillend mee om. Soms zijn zelfs de frontenders de baas: die mogen zeggen hoe het eruit moet zien. Bij ons was het team nog te klein om daar echt een call in te maken; we hebben gewoon samen alles zitten bedenken.

GraphQL zou ook perfect voor mobiele apps zijn. Mobiele developers komen er wel uit met hun client-side iOS of Android apps, maar ooit moet je data opslaan of opvragen van een server ergens, en dat is niet echt een opgelost probleem in die wereld, zeker niet als je moet koppelen op een bestaande API van een grote klant. Meestal zet je er dan zelf een proxy server tussen, maar dat vergt ook weer zelf nadenken over hoe de API werkt, welke technieken je wilt gebruiken, hoe je omgaat met veranderingen en beheer, etc. Veel partijen zijn dus bezig geweest om dit goed op te lossen, van Parse tot Meteor tot Firebase, en we hebben ze allemaal wel eens uitgeprobeerd. Vaak gebruiken we nog Meteor servers omdat dat gewoon lekker makkelijk werkt. Maar door een GraphQL server tussen je mobiele app en de bestaande backend te zetten, kun je heel makkelijk een abstractie bouwen waar over al die dingen is nagedacht. Al helemaal met Apollo, want ze introduceerden bij de conferentie ook hun eerste release van Apollo voor iOS, inclusief code generation. Kijk:

Voordeel daarvan is dat je in Xcode realtime code completion gegenereerd krijgt op basis van je schema en queries. Dus ons iOS team moet dit eigenlijk ook uitproberen!

Al met al was het een optimistische conferentie met een boel forward-looking lui die allemaal samenkomen om eens en voor altijd API’s op te lossen. Hopen ze. Zouden we dan eindelijk eens uitkomen op dat jaren ’70 beeld van autonome systemen die naadloos met elkaar kunnen samenwerken omdat ze allemaal dezelfde taal spreken? XML zou dat zijn geweest, he? Maar toen kregen we SOAP…