It's good to hear that there are some REST people that are open to potential alternatives :)
> I've been writing my APIs as GraphQL first. Then putting a very light wrapper around GraphQL to expose a REST interface. The REST interface is gold standard (HATEOAS, Json-API, etc) yet it is only a few lines of code. I just have a dictionary of REST -> GraphQL mappings and transform the GraphQL result to Json-API.
I'd certainly agree there. This could change in a year or two, but right now REST-ish APIs are still indisputably dominant. If you want to maximize your developers' experience, it's still too early to _require_ that they use GraphQL because there are going to be a lot of shops out there that are just not set up for it. Of course there is still the option of providing your own libraries and tooling for your users to go through, and if you go with that then the API's implementation is much less important.
It uses postgrest but not postgraphql, actually not even the graphql-js reference implementation
It can readily convey graph information, e.g. what are the first and last names of the friends of the friends of user 123? But yes, there's nothing really graph specific.
If it bothers you that "Graph Query Language" is too specific, just remember that "Structured Query Language" is too general :)
But in my opinion, the answer is: write code once, expose both interfaces.
Here's what I mean...
I've been writing my APIs as GraphQL first. Then putting a very light wrapper around GraphQL to expose a REST interface. The REST interface is gold standard (HATEOAS, Json-API, etc) yet it is only a few lines of code. I just have a dictionary of REST -> GraphQL mappings and transform the GraphQL result to Json-API.
Then I also expose the GraphQL interface. So users that want to use GraphQL can.
It's a win-win and it didn't take me any more time to develop than just REST. As an added bonus, the GraphQL code is inherently easier to unit test by nature.
GraphQL has a lot of flaws (for one it has nothing to do with graphs -- nearest I can tell the name is only because it was first used for Facebooks graph database) and things like pagination and error handling have no standard way to do them. But it is very flexible.