Parallelize loading included objects

[mtrezza]

New Feature / Enhancement Checklist

• [x] I am not disclosing a vulnerability.
• [x] I am not just asking a question.
• [x] I have searched through existing issues.

The following description was taken from @noahsilas who is the original author of the related (but stale) PR https://github.com/parse-community/parse-server/pull/6501.

Current Limitation

When preloading multiple fields, we can get some extra performance by doing multiple fetches simultaneously.

Feature / Enhancement Description

The solution here is to build what is basically a dependency graph out of promises; each include path blocks while it is waiting for whatever path it depends on to finish loading. Finally, once we have that graph, we return a promise that depends on every node in it.

Aside: Technically we only need to depend on leaf nodes, but there shouldn't be any meaningful difference between waiting on the leafs and waiting on the entire graph, and this way we don't have to do any analysis to find the leafs)

Example Use Case

Consider a query fetching comments, and requesting that ParseServer preload "post" and "author" pointers:

GET /classes/Comment?include=post,author

In this case, we first need to fetch the resulting "Comment" documents, but after that we should be able to fetch the documents referenced by the post and author fields of the results simultaneously, as they don't depend on each other at all.

Things get a little trickier when we have nested fields:

GET /classes/Comment?include=post,post.author,post.category

To resolve this query, we first need to fetch the related posts, and only once we've added the data about those posts into the results tree can we scan it for the post.author and post.category pointers. But, once that first fetch is completed, we can unblock both of those nested queries!

Alternatives / Workarounds

n/a

[parse-github-assistant[bot]]

Thanks for opening this issue!

• 🎉 We are excited about your ideas for improvement!

[Moumouls]

This feature will also drastically improve GraphQL API. This PR is challenging and interesting to develop. I'll see one of my colleagues and I can dedicate a coding pair session to effectively address this issue in a readable manner.

The dependency graph is the right way to go.