I see GraphQL as a primarily organizational tool. If, for whatever reason, it is too difficult or costly to get frontend teams and backend teams aligned on the precise functionality of a REST API, GraphQL provides a spec that is almost certainly able to satisfy frontend requirements at the expense of nontrivial backend complexity.
This could arise if the backend team is producing an API for public consumption or consumption by many frontend teams with differing requirements.
I consider this a fairly narrow niche - the typical case of a backend serving a small number of frontends with tight collaboration between backend and frontend teams is, to my eyes, almost always handled more efficiently by standard REST.
Comments
I see GraphQL as a primarily organizational tool. If, for whatever reason, it is too difficult or costly to get frontend teams and backend teams aligned on the precise functionality of a REST API, GraphQL provides a spec that is almost certainly able to satisfy frontend requirements at the expense of nontrivial backend complexity.
This could arise if the backend team is producing an API for public consumption or consumption by many frontend teams with differing requirements.
I consider this a fairly narrow niche - the typical case of a backend serving a small number of frontends with tight collaboration between backend and frontend teams is, to my eyes, almost always handled more efficiently by standard REST.