Zo kan er bijvoorbeeld een adres opgehaald worden en het actuele lokale weer via een andere bron. En dat alles in één request.
Foutafhandeling
GraphQL gebruikt een "strong type system" om de definitie van de API vast te leggen. Alle types die worden opengesteld via de API worden in het schema gezet gebruik makend van de GraphQL Schema Definition Language (SDL). Dit schema fungeert als contract tussen de client en de server voor hoe een client de data kan bevragen. Als er dus wordt gecommuniceerd op een manier die niet voldoet aan het gedefinieerde schema kan er een gestructureerde specifieke foutmelding worden gegenereerd door GraphQL die precies aangeeft wat er niet klopt. Ontwikkelaars hoeven dit hierdoor niet zelf te maken zoals bij een REST service en kunnen ervan uitgaan dat data voldoet aan de criteria in het schema.
Performance
Natuurlijk is er een kleine performance penalty bij het implementeren van GraphQL omdat het een extra stukje software is boven op de data op de server.
Het niet hoeven doen van meerdere requests maar alles in 1 request op kunnen halen biedt wel erg veel performance winst, hoewel het maken van een specifieke REST API gemaakt voor dat specifieke doel natuurlijk nog sneller kan zijn.
Hiernaast is er geen overfetching (het downloaden van data die je niet gebruikt) waardoor de bandbreedte en beide systemen minder worden belast.
Underfetching is met GraphQL ook geen issue aangezien alle data meteen kan worden opgevraagd in één request en er dus geen extra informatie hoeft te worden opgehaald als uitbereiding op eerder opgehaalde data.
Een nadeel is dat alle combinaties van data kunnen worden opgevraagd en het dus erg moeilijk is om te voorspellen hoe veel en welke data elke request zal opvragen van de server. Het kan dus zo zijn dat bepaalde request of combinaties van requests erg zwaar blijken te zijn voor de server. Dit maakt optimalisatie van requests ook moeilijker.
Het cachen van GraphQL requests is een stuk complexer dan bij bijvoorbeeld REST. Normaal wordt gecached op basis van een unieke URL, bijvoorbeeld: "/V1/users/<id>". Bij GraphQL is dat niet mogelijk omdat de endpoint altijd hetzelfde is. Het zal dus moet gebeuren op basis van de query in de body van POST die GraphQL doet. GraphQL API’s creëren daarom zelf zo’n unieke identifier uit de request payload. Hoewel het hierdoor mogelijk is requests te cachen met GraphQL zijn er natuurlijk vele malen meer combinaties van velden mogelijk dan bij een REST API en zal het potentieel daardoor minder effectief zijn.
Gebruik van GraphQL heeft de neiging om zwaar(der) te zijn voor de server en daardoor wordt caching en optimalisatie extra belangrijk
Sneller onafhankelijk kunnen ontwikkelen
Niet in alle situaties kun je als frontend ontwikkelaar direct snel schakelen met de ontwikkelaar(s) van de backend of is de backend zelfs in eigen beheer. Dit maakt het soms lastig om gewenste wijzigingen op een service voor functionaliteit in de frontend snel voor elkaar te krijgen. Hierdoor ontstaan vaak vertragingen in een ontwikkeltraject.
Als meerdere partijen gebruik maken van dezelfde API, de backend en frontend ontwikkelaars werken in een ander tempo of niet in eenzelfde team kan het ook lastig zijn om services te veranderen. De software aan de andere kant zou door de aanpassing tenslotte niet meer kunnen werken.
Bij GraphQL ben je volledig vrij om andere data aan te spreken binnen hetgeen beschikbaar is gesteld zonder dat de service moet worden aangepast. Dat maakt dat ontwikkelaars van de verschillende lagen van een applicatie minder vaak hoeven te overleggen en veel onafhankelijker kunnen opereren.
Documentatie
Waar het vaak bij software ontbreekt aan goede documentatie is dat bij GraphQL door het schema en type systeem al "out of the box" geregeld.
Doordat alles al in de schema’s is vastgelegd kan GraphQL zelf documentatie genereren. De gebruikte tool waarmee query’s en mutaties kunnen worden geschreven, uitgeprobeerd en waarin de documentatie kan worden bekeken is GraphiQL.