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.
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.
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.
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.
I mean, just look at the official guide on this: https://graphql.org/learn/pagination/
And that only covers a simple use case!
Graphql allows you to paginate several collections in the same call, but you certainly don't have to. You can do just like REST and do one at a time.
Where did you get this idea that REST in any way dictates how you do pagination?
As far as I know, JS clients Lokka and Urql are pretty small and cloud be easily ported to a different language.
My point remains, why write queries when you can query endpoints and write filters easily without having to learn a new query language?
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.