GraphQL allows you to do things though like query for nested data structures without making round trips, require typed arguments for queries, and pass arguments to specific fields, things that would take a bit of doing with a non-GraphQL api.
It's certainly not perfect, for example I at least have found query tuning for large nested queries to be a bit more complicated than I'd like it to be, but overall I've had a really positive experience with it and unless I have a good reason not to will be using it for any apis I'm building going forward.
We discussed GraphQL internally, and came to the conclusion that it mostly makes sense as a performance optimization, which was its original use case, and not as an "alternative" to REST APIs.
Drawbacks:
- you loose the ability to easily cache
- your API is more strongly coupled to your data model, which makes evolving it more difficult
So GraphQL makes sense when
- data size / performance is key
- the app is mature and the data model doesn't change very much
The other non-obvious thing is it has been easier to introduce people to use, especially newer programmers. Being able to walk through examples in the browser, all on the same endpoint, just makes it a lot easier for sharing the concept of getting data. Though it may speak to the fact that our audience is primarily people seeking data, not trying to perform actions.
I wonder if there would be any interest(or even feasibility) in implementing a REST api data explorer that wraps the REST Api into a GraphQL endpoint so you can have similar discoverability without having to rewrite your entire back end.