-
Notifications
You must be signed in to change notification settings - Fork 149
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Schema and Resolver Pre-compile #3836
Comments
I totally agree, for me this is also a very big issue. |
yes me too. neo4j services are the slowest from my side. |
This is an issue for me as well, but this issue is a duplicate of #243, please express your interest there by adding a reaction (👍) to the first post. |
@mathix420 I just put the discussion topic in a new ticket and marked it as a feature request. Nevertheless, I would also like the problem to be addressed, as it could be a showstopper if it is not solved. I have therefore of course also left my thumbs up there. 👍 |
Got it, so you might be interested by my comment there #243 (comment) |
Pre-compilation like this is also useful for tooling that takes schema / type-defs for explorer views, internal tooling, etc. |
Is your feature request related to a problem? Please describe.
Schemas and resolvers are regenerated at every server startup. Especially with a large schema, this leads to long startup times.
For use cases like autoscalling and cold starts (serverless) this is a big problem. The startup can take several seconds for large schemas, making the use of autoscalling and cold starts impractical.
Describe the solution you'd like
As already discussed in #243 (@mathix420) the possibility of a pre-compile would be perfect to solve this problem. For example, this could be solved via a specialized Neo4j GraphQL plugin for graphql-codegen.
Describe alternatives you've considered
?
The text was updated successfully, but these errors were encountered: