Comment by elnygren | Hacker News Reader

Comment by elnygren | Hacker News Reader

GraphQL is a very nice spec for building APIs that have many sources of data and then building a modern frontend with proper caching etc. on top of it.

The ugliest part of it, or one requiring most hacky solutions, is optimising queries. For example, there are some nasty N+1 traps or "oops-I-joined-your-entire-database" problems when using SQL.

JoinMonster helps with this, but it is a bit too much of a "full solution" or framework to just quickly use. You'll also lose a lot of control over your queries which was a big reason for me to move from Django/Rails/etc. style tools to trying out GraphQL.

This project seems to avoid databases entirely and it seems to have an N+1 queries problem when fetching comments. Each comment is fetched with a separate API call and a single HN Post can easily have hundreds of comments... even if cached, this is a problem.

The SQL "WHERE IN (list of IDs)" query combined with smart caching and batching (see: Dataloader by Facebook, JoinMonster) is a decent solution but requires some amount of good old manual work.

tldr; GraphQL is nice but has its own set of problems. Still no magic bullets.

> You'll also lose a lot of control over your queries which was a big reason for me to move from Django/Rails/etc. style tools to trying out GraphQL.

For restricting queries, an option is using persisted queries (e.g. https://dev-blog.apollodata.com/persisted-graphql-queries-wi...).

The idea is nice, having full control in development while locking down allowed queries in production.

You'd still have to deal with the problems you mentioned in development, some of which are indeed a little ugly (at least currently).

Actually, my point was about losing control over queries when using JoinMonster (say, you wanna do something fancy like Postgres' to_json, array_agg that JoinMonster doesn't support).

However, I totally understand the confusion in my sentence and actually this thing you're talking about is also useful to me :)

Can't you translate GraphQL queries to Joinmonster/Dataloader/Haxl calls? It's up to the implementor of the GraphQL <-> backends layer to build these optimisations, and you could reuse those libraries for that.

Haxl seems particularly suited for this (I think it's the same thing as Dataloader, both from facebook?) as it can efficiently batch and cache queries to multiple sources at the same time. It seems like a good layer between GraphQL and your N data sources.

It's certainly doable and has been done. However, it's not as pretty as the rest of GraphQL and there's still a lot of work to be done.

And comparing to something like Django/Rails - there's a lot more DIY involved.

Don't have tones of experience with GraphQL, but doesn't one write resolve methods himself? GraphQL just works with the data you've fetched, and as always it's up to the developer to know how to use the tool properly

I think that's sort of the point: You have to write this layer yourself, whereas you get it "for free" when you use Rails/Django/etc.

Reply on news.ycombinator.com