TestAutomatisering & PerformanceTesten

Meer efficiency en flexibiliteit in API’s

Er wordt steeds meer gebruik gemaakt van GraphQL API. Tijdens mijn laatste opdracht heb ik hier dan ook mee gewerkt.. Graag deel ik mijn ervaringen hierover in een aantal blogs. In deze eerste blog wil ik het graag hebben over de uitdagingen met REST API en hoe GraphQL deze oplost.

Maar eerst even een korte introductie in REST API. We leven in een wereld waarin alles en iedereen door technologie met elkaar is verbonden. Hoe we dat doen? Met API’s, application programming interfaces. Bij het bouwen van een applicatie wordt vaak voor RESTful webservices gekozen om de applicatie met de buitenwereld te verbinden. REST staat voor REpresentational State Transfer.  REST API’S definiëren een set aan functies welk de ontwikkelaars/testers kunnen uitvoeren bij het doen van requests en ontvangen van responses via HTTP Protocol zoals “GET”, “PUT”, “POSTS en “DELETE”.

Het gaat hierbij om het representeren van resources zoals foto’s, webpagina’s, profielen, artikelen, videoclips etc. via een client-server model. Bij het intypen van een URL in een browser of het klikken op een webpagina link doe je een request naar de webserver en ontvang je een response vanuit de webserver in de vorm van een resource terug. De webserver geeft dus niet een specifiek database als response terug, maar juist een representatie van de database in een formaat wat leesbaar is voor de gebruiker, bijvoorbeeld een HTML pagina of een XML/JSON bericht. Het klikken, scrollen of swipen op webpagina onderdelen geeft je continu een andere staat van de webpagina aan. De resources worden vervolgens in verschillende formaten vanuit de webserver overgedragen naar je webclient. Een REST API is dus een communicatie protocol tussen front-end en back-end.

Ongetwijfeld heb je ook over GraphQL gehoord, een open source data querytaal en runtime omgeving die je in staat stelt om een applicatie met de buitenwereld te verbinden. Is dit de eerste keer dat je van GraphQL hoort? Dan heb ik hier een interessante feit: je hebt het al gebruikt of gebruikt het nog steeds! Facebook heeft in 2012 GraphQL intern ontwikkeld en in 2015 op de markt uitgebracht. Het gebruik maken van Facebook betekent dus automatisch het gebruik van GraphQL en dit is bedacht om een aantal uitdagingen die worden ondervonden bij het gebruik van REST API’s op te lossen. Voornaamste doel is om de data uitwisseling tussen API’s en front-end applicaties eenvoudiger, efficiënter en flexibeler te maken.

Uitdaging 1: Multiple Endpoints

Web en mobiele applicaties zijn steeds meer data-driven en vereisen grote datasets die gerelateerde resources combineren. Om de volledige data op te halen, ook wel “fetching” genoemd, moet men via een REST API vaak meerdere calls uitsturen om alle nodige data te verzamelen om het uiteindelijk aan de gebruiker te representeren. Als een gebruiker bijvoorbeeld op de website van de Telegraaf een opmerking op een willekeurige artikel pagina met een profielfoto en de naam van de auteur opvraagt, dan wordt bij het opvragen van deze data driemaal een roundtrip naar de server gedaan om uiteindelijk over de volledige data te beschikken. Er wordt dus een call gedaan voor zowel de opmerking op de artikel pagina als voor de profielfoto en de naam van de auteur.

Met behulp van GraphQL, waarin QL staat voor “Query Language”, kan men zelf query’s samenstellen en hierin zelf exact duidelijk maken wat diegene van de API nodig heeft. De runtime omgeving  vertaalt deze query’s naar functies om data op te halen en eventueel te wijzigen. Waar REST API meerdere endpoints nodig heeft voor het ophalen van data, heeft GraphQL er slechts één nodig.

Kortom: met een single endpoint kan GraphQL de exacte data ophalen om deze aan de gebruiker te representeren. Niet meer en niet minder! Op deze manier creëer je efficiëntie in je architectuur.

Uitdaging 2: Overfetching & underfetching van data

Een ander probleem die veroorzaakt wordt bij het gebruiken van een Rest Service is overfetching en underfetching. Met overfetching wordt bedoeld dat de client data ophaalt welke niet noodzakelijk is. Meer data is meer benodigde tijd om de gevraagde data te parsen en te downloaden, waardoor de performance verslechtert. Uit ervaring weet ik, dat in vele gevallen bij het ophalen van klantgegevens zoals naam, achternaam, geboortedatum, adres, woonplaats vanuit de server vaak ook een profielnaam en profielfoto meegegeven worden. De laatste twee worden niet benut en het fetchen van deze data is daarom niet noodzakelijk – You ain’t gonna need it (YAGNI)! Underfetching is het tegenovergestelde van overfetching en houdt in dat er niet voldoende data is voorzien in de Rest Service. De client dient een additionele call te doen om de gewenste data op te halen vanuit de server. Je kunt dit oplossen door specifieke API endpoint te bouwen op de databehoeften van front-end applicaties. Je creëert dan wel meerdere endpoints, waardoor het managen van API’s in je front-end zeer inefficiënt kan worden. Daarnaast is het onderhouden van deze endpoints arbeidsintensief en worden met de tijd onoverzichtelijk.

Uitdaging 3: Geautomatiseerde documentatie

Bij een technische omgeving maakt men vaak gebruik van een REST API documentatie – swagger –  waarin verschillende endpoints met de bijbehorende versies zijn beschreven en deze ook hierin worden onderhouden indien zich wijzigingen voordoen in de applicatie. Het voordeel van GraphQL API’s is dat deze zijn opgebouwd in types & fields en niet in endpoints. Het kloppende hart van een GraphQL API is het schema. In het schema definieer je welke query’s allemaal tegelijk mogelijk zijn op de API. In het schema worden alle objecten en velden vastgelegd die de gebruiker kan opvragen, eventueel met de benodigde relaties van deze objecten.  Daarnaast wordt als ondersteuning een tool, GraphiQL, meegeleverd die naast je GraphQL server draait waarmee het schema van de API in een web interface wordt weergegeven en de gebruiker automatisch suggesties krijgt bij het invoeren van de query. GraphiQL verzorgt voor een volledig geautomatiseerd documentatie van de GraphQL API en maakt deze op een centraal repository beschikbaar voor de verschillende API’s, hetgeen leidt tot front-end ontwikkelaar/tester gebruikersgemak.

Conclusie

In deze blog heb je vooral over de verschillen tussen GraphQL en REST API gelezen. Ik zou zeggen probeer eens GraphQL uit! Door de parallelle samenwerking tussen front-end engineers en back-end engineers kun je sneller features ontwikkelen. Je hoeft dus niet meer te wachten totdat de back-end engineers ontwikkeld hebben om de front-end applicatie op aan te sluiten. Ik ben van mening dat GraphQL de toekomst is en het ziet ernaar uit dat GraphQL API razendsnel populair wordt en de harten van ontwikkelaars veroverd. GraphQL API dient zeker niet als vervanging van de huidige REST API architectuur gezien te worden, maar juist vooral als alternatief. In mijn volgende blog ga ik verder in op het opzetten van GraphQL server met schema om mutaties uit te voeren. Wil je meer weten over GraphQL, dan kun je de volgende webpagina bezoeken: https://graphql.org/.

Dit bericht is geplaatst in Agile Testautomatisering en getagd in API GraphQL Rest

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Nieuws

Blijf op de hoogte

Ervaringen Performance.Now() 2019

13/12/2019

Ervaringen conferentie PerfNow

Performance test in de pipeline

25/10/2019

In deze blog geef ik kort en bondig neer in welke opzet en met welke tooling ik performancetesten heb geïntegreerd in de pijplijn bij mijn huidige opdracht.

Circle-CI, van code naar webserver met één klik.

13/09/2019

Wanneer je ‘vroeger’ een website had, waren er altijd flink wat handelingen nodig om files via een FTP client op een webserver te krijgen. Vandaag de dag, met behulp van een verscheidenheid aan tooltjes, is dat een fluitje van een cent. Daarnaast krijg je een arsenaal aan mogelijkheden mee als builden, testen, etc.. In deze […]

Een korte intro in data-analyse met R

10/07/2019

Een blog over hoe je met behulp van R grote hoeveelheden data kan analyseren. Een tool dat je helpt bij de analyse van bijvoorbeeld load- en stresstestresultaten.

Installatie Oracle ATS op Windows

28/03/2019

Handleiding over hoe je Oracle ATS installeert op Windows (Versie 13.x of hoger)

Postman API testen in CI

01/02/2019

beschrijving van hoe je jouw Postman collectie laat draaien vanuit Jenkins en hoe je hierbij een praktisch JUnit test report krijgt.

Workshop ‘Stop de Magie!’ bij Qquest

04/12/2018

In het kader van de 4e techday van Qquest heeft Chris met ondersteuning van HenkJaap een workshop gegeven. Basis was de presentatie en demo ‘No more magic’ van Bas en Chris, welke al een groot succes was op de TestAutomationDay en TestNet. Centraal bij het onderwerp ‘No more Magic’ staat het idee dat er bij […]

Visual Regression Testing – Wat is het en wat heb je eraan?

07/11/2018

Visual Regression Testing, of visuele regressie testen, is een categorie van testen die zich focust op het identificeren van visuele wijzigingen tussen iteraties of versies van een website. Dit kan handmatig door schermen of schermafdrukken te vergelijken, maar het is beter herhaalbaar en sneller te testen door dit automatisch te doen. Het mooiste is om deze testen als een […]

Meer efficiency en flexibiliteit in API’s

04/10/2018

Er wordt steeds meer gebruik gemaakt van GraphQL API. Tijdens mijn laatste opdracht heb ik hier dan ook mee gewerkt.. Graag deel ik mijn ervaringen hierover in een aantal blogs. In deze eerste blog wil ik het graag hebben over de uitdagingen met REST API en hoe GraphQL deze oplost. Maar eerst even een korte […]

Impact tooling op performance: Dynatrace

21/09/2018

In deze blog geef ik kort de resultaten weer van een onderzoekje dat ik bij één van mijn laatste opdrachten heb gedaan naar de impact van het gebruik van de tool Dynatrace op de infrastructuur waar het op draait. Mocht je gebruik maken van tooling als Dynatrace of op een andere manier geïnteresseerd zijn in […]

Tips en tricks voor Protractor

06/09/2018

Vanuit PerformanceArchitecten doen we graag aan kennisdeling. Van tool reviews tot aan complete best practices maar ook van een aantal simpele tips en tricks die je kan gebruiken in je dagelijkse werk. Vandaag in die laatste categorie voor gebruikers van Protractor: (Javascript) timing issues en het managen van de volgorde van uitvoeren van actions. Inleiding […]

PerformanceArchitecten @The Next Web conferentie

04/07/2018

Was het een interessante conferentie? Beslist. Heeft TNW PerformanceArchitecten op nieuwe ideeën gebracht? Zeker. Heb jij TNW gemist, maar wil je je wel in vijf minuten op de hoogte laten brengen? Lees dan snel verder! En mocht je er wel zijn geweest.. We zijn benieuwd naar jouw beeld! Wat is de Next Web? Voor hen […]