Hacker News Reader

Comment by georgyo | Hacker News Reader

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.

View on HN

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.

Is it so hard to create a GraphQL client?

As far as I know, JS clients Lokka and Urql are pretty small and cloud be easily ported to a different language.

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.

I mean, just look at the official guide on this: https://graphql.org/learn/pagination/

And that only covers a simple use case!

I've implemented the connection spec many times and I find it very clear and usable.

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.

> With rest, you can only paginate that particular call. You cannot really paginate different results in that one call.

Where did you get this idea that REST in any way dictates how you do pagination?

Dunno if it'll help at all, but I did write a thing about GraphQL connections that may clear up some things: https://andrewingram.net/posts/demystifying-graphql-connecti...

Hand crafting GraphQL queries is pretty easy, with auto-suggestion built into every client like GraphiQL for example.

But but isn't GraphQL the swiss army knife where you don't have to write queries anymore as some posters suggest?

My point remains, why write queries when you can query endpoints and write filters easily without having to learn a new query language?

Reply on news.ycombinator.com