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.
A most_recent_articles view?
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?
- 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.
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.
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.
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.