You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is there an existing issue that is already proposing this?
I have searched the existing issues
Is your feature request related to a problem? Please describe it
In a large GQL application with 100s of schemas the bootstrap time for the Nest app is extremely slow.
This is caused mainly because of type-metadata.storage.ts which stores all the metadata in flat arrays.
On app startup, the class iterates over every GQL annotated class, and its fields, methods, their arguments and so on. Since all of the metadata is saved in arrays, this causes multiple iterations over each array with multiple levels of nesting.
Example: For a project with 100 GQL classes, with each 50 fields and methods (5,000 fields total), and 10 arguments per class (1,000 total), the recursion is as follows: 100 * 5,000 * 1,000 = 500,000,000
Describe the solution you'd like
Changing the data store models to Maps would result in O(1) access which would greatly optimize the startup time
we could use, for example, interfaces[target] (or .get(target)) instead o using the find() method? If so, I'm all in for this change. The reason we've been using arrays is that we had to stay compatible with the type-graphql library (see comment at the top of the class declaration) which is no longer the case.
Is there an existing issue that is already proposing this?
Is your feature request related to a problem? Please describe it
In a large GQL application with 100s of schemas the bootstrap time for the Nest app is extremely slow.
This is caused mainly because of type-metadata.storage.ts which stores all the metadata in flat arrays.
On app startup, the class iterates over every GQL annotated class, and its fields, methods, their arguments and so on. Since all of the metadata is saved in arrays, this causes multiple iterations over each array with multiple levels of nesting.
Example: For a project with 100 GQL classes, with each 50 fields and methods (5,000 fields total), and 10 arguments per class (1,000 total), the recursion is as follows: 100 * 5,000 * 1,000 = 500,000,000
Describe the solution you'd like
Changing the data store models to Maps would result in O(1) access which would greatly optimize the startup time
Teachability, documentation, adoption, migration strategy
No response
What is the motivation / use case for changing the behavior?
Faster NestJS bootstrap time on large GQL projects
The text was updated successfully, but these errors were encountered: