[tango12]

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.

[tango12]

@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.

[alex_lav]

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.