Is there a way to statically generate schema.json,

[mattchristenson]

Hi there! I am running into an issue with how to work this library into our CICD pipelines.

We need to generate our schema file at build time, instead of at runtime, so that it can immediately be available to a client library that should build right after the server builds, so that we can deploy the client and server together.

I have been unable to find a way to have this happen. Does anyone know of a way that would allow us to, without launching our whole solution that requires dependencies like databases, run just enough of the program to have a schema file generated that we can consume during out build scripts?

Thanks so much!

[Shane32]

As part of our CI/CD pipelines, I have a test that produces and verifies the schema definitions; developers need to update the SDL file in order for tests to pass. This ensures that changes to the schema are verified during development (upon PR approval), and I find that it also helps to verify nullability and naming of fields and types easily. It is easy enough to update the test so that it automatically updates the schema file if there is a change. This still allows the benefit of seeing changes to the schema within the PR for approval.

I would imagine that it would be easy to update build scripts to use this file that was generated during tests. Assuming you only publish/build your project once tests pass, then the build would always have the correct schema file for use as you see fit.

Assuming you have tests configured already, this might be very simple to implement. And assuming you have at least some tests configured, it should be rather simple to set up a schema test as I described. Perhaps you might need to mock some services which configuring the temp DI provider (e.g. services.AddSingleton(Mock.Of<IMyService>(MockBehavior.Strict))), but that should be it, since the resolvers won't actually run when the schema is built or printed.

If you'd like additional details on how I implemented this, lmk.

[Shane32]

Note that the SchemaPrinter outputs in SDL (schema definition language) as defined by the GraphQL specification. If your client code requires the json output of an introspection query, that would not be difficult to implement under the same principles.

[mattchristenson]

Thank you so much for taking the time to share this, @Shane32 ! This is helpful for us. Shamefully we don't have any unit testing against this project yet - all of our business logic is encapsulated in a separate library and through interfaces, so this webapi app is really just a shell around that, with our graphql mappings (we had to do some weird things to get generics to work right). We have not yet tackled building out a test suite testing the api project itself - so we will now prioritize that, thanks to your direction!

[sungam3r]

Regarding #980 (comment) - I did the same across our services codebase - dedicated GraphQL API approval test for each service with SchemaPrinter + some mocks inside.

[sungam3r]

I strongly recommend to use SDL instead of json introspection. SDL is intended to be human readable, introspection json - not.