In de eerste drie delen van deze serie hebben we GraphQL leren kennen als een getypeerde querytaal met een fundamenteel ander model dan REST (deel 1), zagen we dat de flexibele bevraging zowel de grote kracht als een serieuze beheeropgave is (deel 2) en liepen we zes ontwerpuitdagingen langs die in de praktijk bepalen hoeveel werk een GraphQL-API werkelijk kost (deel 3).

In dit slotdeel komen we bij de vraag waar het allemaal om draait: wanneer is GraphQL een passende keuze, en wanneer ben je met REST beter af? Er zijn omstandigheden waarin het ene model aantoonbaar beter past dan het andere.

Iedere gebruikerstoepassing heeft een specifieke informatiebehoefte, die in veel gevallen meerdere databronnen overstijgt. Toepassingen moeten in dat geval in staat zijn om op een betrouwbare manier gegevens van meerdere bronnen te raadplegen en waar nodig met elkaar te combineren tot het gewenste informatieproduct in de ‘taal’ van de gebruiker.