Schema generation at build time

[ramiel]

Is your feature request related to a problem? Please describe.
This is more an idea/investigation. Building the schema takes time and so it's common to build it once. This is fine for normal server but the build time occurs often for ephemeral environments such as AWS Lambda or any other FaaS env.

I'm trying to understand if it's possible to generate the result of buildSchema (which should be JS code as far as I understand) at build time. Very similar to what prisma does with its client.

This should reduce the start time nearly to 0 also in lambda contexts

Describe the solution you'd like
As above

Describe alternatives you've considered
I'm trying to understand if it's possible to achieve the same result from outside the library, but it's not clear to me

Note: this is just an idea, please feel free to ignore me if this makes no sense :)

[MichalLytek]

It's not possible to generate it all on build time. The schema contains tons of references to runtime values, like classes (converting args, calling resolver methods, etc.).

Even the reflection part is hard to "Serialize" as it has to link to the runtime class objects.

All I can think of is to somehow serialize the schema info using some syntax like Resolver#TestResolver and then try to replace it with the value from resolvers array on runtime. However then we have issues with args, input and object type instances, we would need to use reflection to load and replace the string ids into real js values.

Please share first your benchmarks with schema size vs generation time, make some investigation which part of build schema is the slowest, maybe we can use some local cache (JS Map/Set) to make it faster.

[john-landgrave]

For what it's worth I have been thinking about and investigating this some as well and I came to a lot of the same conclusions that you did, @MichalLytek. In the end there has to be some sort of "hydration" step even if you have a serialized format to store the schema object in some sort of static representation.

From what I understand about how/why the prisma client is built and deployed it is because they have basically created a compiled binary that should provide very fast processing and execution of your queries. It isn't really concerned about the idea of validating GraphQL requests and such, which is why we need the schema (for apollo server or whatever to interpret the requests). I like the train of thought, @ramiel, and I will continue to think on it as well, but I don't know if there is a solution here.

@MichalLytek how do you quantify "schema size"? I have a timer sitting around specifically the schema generation in our app, but I need to know how to contextualize that for you.

EDIT: Forgot that this wasn't the typegraphql-prisma repo again. Sorry!

[tanohzana]

Same issue here. We have a long prisma schema (99 models + some enums) to generate our resolvers, and it takes roughly 7 seconds on my 2022 M2 MBP to start the app because of the buildSchema function 🤔