4 Comments

But the last line in your post is the most interesting one :)

That's exactly the solution for this issue as I see it. You get all the benefits of a GraphQL schema where developers can pick and choose the data they need without having to use a set of very specific queries (probably also with the cost of overfetching as is the usual cost of using "generic" REST endpoints).

Once you DO know which queries are the important (and slow) ones, you add a very specific resolver for those and developers consuming the api will now be able to use that resolver for improved performance.

Expand full comment

For the one-shot resolver solution, if the client doesn't request the items in the GraphQL query, you will still query them in the database even if you don't need them. So it may not be optimal for all use cases.

Expand full comment

This make no sense!

details: {

id: details.id,

...details

}

Expand full comment

Quick question -

When you used data loader , did you batch the queries? Since items are child of the user parent resolver there will actually be only 2 async hooks one to fetch user and one to batch request all items according to the parent (user ) item list.

Then how did for each user and each item a new async hook was created during your analysis even with data loaders?

I think you should explain the overhead added in the example in a bit more detail.

Expand full comment