5 ms·
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 ugl
by elnygren 9y ago
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.
- arianvanp 9y agoCan'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.
- elnygren 9y agoIt'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.
- aocvr 9y ago> 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-with-apollo-client-119fd7e6bba5 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).
- elnygren 9y agoActually, 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 :)
- ivanhoe 9y agoDon'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
- RussianCow 9y agoI 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.