CODEWITHSUNDEEP
typescriptdockergraphql
Charklewis
Charklewis

Reputation: 5661

Best practices on managing a generated graphql schema in Typescript applications

I am having some issues working out the best strategy for managing generated graphql files. The problem that I am having is we have a dev ops pipeline that uses docker to build two containers, with one container building the schema based on the first.

The two containers are a Hasura database and an express server (in Typescript).

The express server uses the hasura database to generate a schema and using this type check the queries/mutations.

To manage the generated schema I have tried the following solutions.

  1. When the express server is built in docker, it has a retry function to keep fetching for the schema from the hasura database. I was quickly told by dev ops that this was a terrible idea to have dependancies between two containers (although I don't really understand why when they have a legitimate dependency with each other).
  2. Compile the typescript in the express server without the graphql schema ignoring the errors this produces. The typescript code is compiled down to javascript and this is used at runtime, so the type checking is only a tool used for static testing. This works, with the Javascript being compiled correctly. However docker errors as the typescript compiler throws an error. I am not sure how to silence this.
  3. Upload the generated schema to GitHub. From what I understand when you are uploading generated files it is a red flag and should be avoided. I can forsee this causing headaches when wanting to work on schemas locally that are slightly different (say the unreleased), and also managing potential merge conflicts.

My instinct is that solution 1 is correct. My docker knowledge is very limited, so is there a correct way to implement this using docker? Or are one of the other solutions a better fit? For now the team has implemented solution 3.

Any tips of help is greatly appreciated!

Upvotes: 0

Views: 192

Answers (1)

Greg Ferreri
Greg Ferreri

Reputation: 2892

I would go with option #3. Committing generated code into a source repository is not always discouraged, and is sometimes the proper course of action. Consider dependency lockfiles (package-lock.json, yarn.lock), for instance.

The generated schema represents a snapshot at the time of development which is the contract that your application expects. I would not want this to be generated at CI time, because it must be known when developing your application client code that depends on the schema anyway. Updating the schema ought to be a conscious decision made while developing your application, and not left to happenstance during your CI/CD pipeline.

Upvotes: 1

Related Questions