NodeJS and GraphQL are popular technologies for building web applications, but in my experience, they come with certain scaling and performance tradeoffs to be aware of. tl;dr: GraphQL's modular structure generally leads to code that instantiates excessive promises, which degrades request performance. Benchmarks show a 2-3x latency increase.
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.
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.
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.
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.
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.
This make no sense!
details: {
id: details.id,
...details
}
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.