A alternate would have been to add Dataloader to the appContext, but the problem with that is would have been difficult to manage and expand overtime.
Use the dataloader over larger time, use it more as a cache with a different lifecycle than that of the request.
Pros of this approach.
This would mean significantly lesser hits to the database and that's amazing.
Cons of this approach
Would be difficult to maintain the lifecycle of the Dataloader and may lead to significant memory leaks and hell.
Additional context / quirks
Add any other context, screenshots, or quirks about the implmentation here.
What Does this PR do?.
Adds Dataloader to the server to batch and cache
Userqueries.Describe In brief the solution / approach you've gone with.
The approach used here uses Dataloader of which a new instance is created on every new connection.
The Dataloader is then made available using dependency injection mentioned here. https://github.com/MichalLytek/type-graphql/issues/51#issuecomment-626719854
Describe alternatives you may have considered
A alternate would have been to add Dataloader to the appContext, but the problem with that is would have been difficult to manage and expand overtime.
Use the dataloader over larger time, use it more as a cache with a different lifecycle than that of the request. Pros of this approach. This would mean significantly lesser hits to the database and that's amazing.
Cons of this approach Would be difficult to maintain the lifecycle of the Dataloader and may lead to significant memory leaks and hell.
Additional context / quirks
Add any other context, screenshots, or quirks about the implmentation here.