The main issue of GraphQL is awful tooling, especially outside of the js.
For example, we have done small rewrite of Apollo Android library and achieved like 100x performance boost simply by writing as it should be written. Literally very minor changes and better DB.
Typesafe codegeneration? Still feels very beta anything your could find.
Compare it to something like grpc that have strict typed clients for almost anything.
100% this! Outside of JS, the tooling seems non existent.
What's so amazing to me is that it is really easy to spin up a server that talks graphql in any language. But there is no client support.
And hand crafting queries is a million times worse than reading the rest documents
Oh, you want to get a list of items by owner, you can do that but you'll also have to paginated the inside and outside list. And the client will have to follow these pages while also having a deep understanding of your model.
Without good client tooling, graphql is a nightmare.
It's easy to spin up a server. Spinning up a server that can actually access your data in a way that has reasonable performance is another matter entirely.
I think this is the important point here; it’s not hard to call GraphQL and even create a client starting from copying @urql/core for instance, but I suppose at some point if you want the same benefits on your other platforms normalized caching will be of interest, which means it isn’t as trivial to get to feature parity. So I think it’s still a valid point
What kind of client side support do you need? You send a query document in a POST and get JSON back. I'm pretty sure all languages have an http client and a json library.
How is pagination worse than the REST equivalent?
I guess I could see a case for client side caching based on IDs, but unless you couple this with subscriptions thats kind of brittle.
The main different on pagination, is that you pages return inside an object. And you have have several different objects that all have different pages.
With rest, you can only paginate that particular call. You cannot really paginate different results in that one call. At most you can do is say get the list of objects at this endpoint. And that is far easier to grok than graphql's pagination in even the simple case.
With WunderGraph I actually want to go the other way around. Instead of having a "smart" GraphQL client I let users write their Queries/Mutations/Subscriptions in GraphiQL. I'll then take the operations and generate a fully typesafe "dumb" client which has no clue about GraphQL at all. The Operation gets persisted as an RPC which the dumb client can then call. Feels like GraphQL, behaves like GraphQL but is very lightweight, performant and secure at the same time. All it takes is one code generation step but I think that's acceptable. GRPC does it the same way.
This was a big reason we decided not to release a GraphQL version of our REST API at my previous employer. Most backend languages have poor gql clients, if any at all.
Better to just provide a nice, typesafe client library generated from OAS.
We are using hasura (which is written in Haskel), I'm interested in dgraph.io (which is golang).
I had terrible experience writing graphql-service in typescript. I finished it but I did not liked it's strange behaviour and bloated docker image size.
I rewrote it in 2 days with graphql-go/go and then it became OK: predictable behaviour and ~16Mb docker image.
I'm thinking about rewriting another service too.
On client side I used:
- python client `gql`
- .NET `graphql-dotnet`
- Apollo client
- graphqurl - js client from hasura team
The worst impressions are from Apollo.
Starting from their documentation.
IDK why they explain everything starting from UI.
I would argue that even in JS the tooling is bad compared to other options. If you can't get autocomplete, strict types, etc out of the box without backflips, it isn't really worth whatever other benefits you may be getting.
For example, we have done small rewrite of Apollo Android library and achieved like 100x performance boost simply by writing as it should be written. Literally very minor changes and better DB.
Typesafe codegeneration? Still feels very beta anything your could find.
Compare it to something like grpc that have strict typed clients for almost anything.