5 ms·
The 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 t
by tango12 3y ago
The 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.