Asynchronous schema generation and OGM initialization #896
Conversation
|
Thanks for the documentation updates. The preview documentation has now been torn down - reopening this PR will republish it. |
|
Great that this is happening. I guess this means you'll be going for a new major release reasonably soon. Any idea of roughly when the release is scheduled? |
Hey @wheresrhys! We wouldn't normally give timelines, but this release has a fairly strict schedule, so you can expect this next week! 🙂 It won't be as much of a jarring release as 2.0.0, but certainly some nice changes to come. |
Co-authored-by: angrykoala <angrykoala@outlook.es>
Co-authored-by: angrykoala <angrykoala@outlook.es>
Co-authored-by: angrykoala <angrykoala@outlook.es>
| @@ -128,6 +128,50 @@ class Neo4jGraphQL { | |||
| await assertIndexesAndConstraints({ driver, driverConfig, nodes: this.nodes, options: input.options }); | |||
| } | |||
|
|
|||
| private wrapResolvers(resolvers: IResolvers, { schema }: { schema: GraphQLSchema }) { | |||
There was a problem hiding this comment.
nitpick (non-blocking): Maybe we could move these functions to the bottom?
Usually, it is slightly easier to read functions in a class from more abstract to less abstract (kind of like articles are composed). So, first, we read generateSchema at the top, and then, if we need to, we keep going to the functions that are used by that one
Description
This PR moves the heavy lifting of the
Neo4jGraphQLandOGMconstructors into asynchronous functions,getSchema()andinit(), respectively.This means that construction will be quick and these functions will have to be awaited following construction. Whilst this may seem like a nuisance right now, in the future this will open doors to more performant schema generation through asynchronous processing.
Checklist
The following requirements should have been met (depending on the changes in the branch):