6 ms·
True - but the important point worth discussing here is that most common GraphQL implementations make it really hard to think in joins. The resolver pattern an
by tango12 3y ago
True - but the important point worth discussing here is that most common GraphQL implementations make it really hard to think in joins.
The resolver pattern and data loader pattern make joins really painful.
eg: implement a simple top-N query (fetch 10 users and the most recent 5 articles for each) in GraphQL with a resolver tree, or even data loader.
- deleted 3y ago[deleted]
- alex_lav 3y ago> eg: implement a simple top-N query (fetch 10 users and the most recent 5 articles for each) in GraphQL with a resolver tree, or even data loader. A most_recent_articles view?
- tango12 3y agoquery { Users (first: x) { …, articles (first: y, sortBy: CREATED) { .. } } } How would one implement the users and articles resolvers - that would be as efficient as a most_recent_views in sql?
- pharmakom 3y ago- Resolver for the most recent articles - Resolver for n users by ID - Caching layer This will be quite performant in general since in worst case we do 2 SQL queries but in most cases we hit a cache.
- tango12 3y agoThe problem is that it’s hard to get the articles resolver make one query to fetch all the recent articles. So you’ll end up with n+1 fetches from the db. In the articles resolver, you have to: Select from articles order by created where article.user_id = X limit 5. And you’ll have to run this statement n times - once for each user. Not sure how a data-fetching cache layer at the app server layer will help here.
- alex_lav 3y agoSorry, I feel like there must be something I'm not understanding about the limitation you're trying to convey. WITH relevant_users AS ( SELECT id FROM users WHERE id IN (1) ) SELECT users.name, mra.title FROM users INNER JOIN most_recent_articles mra ON users.id = mra.user_id INNER JOIN relevant_users ON users.id = relevant_users.id; This is a single query that can fetch users filtered by the First: (although I just did in, you could add whatever filtering options you wanted in the relevant_users cte) with the most recent articles view we've discussed previously.
- deleted 3y ago[deleted]
- tango12 3y ago@alex_lav: Your SQL query here is exactly what I meant! In SQL, this is easy, both to write and to optimize perf. Implementing this with GraphQL resolvers (how folks typically write GraphQL servers) is hard - there's a users function and an articles function that are both called, so it's hard to implement those 2 functions contributing together towards a query plan. This was my point. In fact a REST endpoint that takes a list of users and runs this query with the `IN` part parameterized is easier to build here. But the GraphQL version is a pain.
- giovannibonetti 3y agoLateral JOIN