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: 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.
Sorry, 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.
- 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.