mathix420
commented
1 year ago An essential feature for serverless environments, but also a huge design flaw in my opinion: makeExecutableSchema should have always meant to be running during build time.
It has absolutely zero advantages nor reasons to be executed during runtime, thus wasting resources and slowing down every graphql server launch.
Around 1.5k repository mentioning graphql and serverless, growing 26k monthly downloads of @as-integrations/aws-lambda and way more stats pointing the fact that this is a major issue.
This of course also apply to any tool meant to only change the schema, like @graphql-tools/merge and @graphql-tools/schema.
Merging 50+ small schemas (10 lines) in a serverless environment increased the cold start of my project to 10s. So I have to stick to a lot less DX friendly solution which is to manage all my 200 types on a single file.
I believe this issue should get a lot more attention than this, and hope will be addressed soon.
When running in serverless environments like AWS Lambda the startup time of the application is of unusual importance. It is valuable to move as much startup operation into the build step as possible, in order to reduce startup time
Describe the solution you'd like
makeExecutableSchemadoes a lot of parsing and object graph construction. This work is slow, heavily impacting the startup time. It would be awesome if this could be done as a build step, with an output of a pre-built JS (or better yet, TS) file that could be loaded at run-time. This would eliminate a costly string-parsing step from startup.Describe alternatives you've considered
The existing solution works, but it is slow.