Skip to content
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

makeExecutableSchema: run as a build step #4270

Open
timkye-blueocean-ai opened this issue Feb 25, 2022 · 1 comment
Open

makeExecutableSchema: run as a build step #4270

timkye-blueocean-ai opened this issue Feb 25, 2022 · 1 comment

Comments

@timkye-blueocean-ai
Copy link

timkye-blueocean-ai commented Feb 25, 2022

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

makeExecutableSchema does 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.

@mathix420
Copy link

mathix420 commented Aug 22, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants