3 ms·

I'd be curious to hear more on your schema validator. We've been using GQL for a little over a year and have felt some serious pain when doing big shifts in our

I'd be curious to hear more on your schema validator. We've been using GQL for a little over a year and have felt some serious pain when doing big shifts in our GQL layer and even just when we're trying to clean out dead code / assess which resources are being used in which FE apps.

maktouch 8y ago
Sure! Our implementation is a little bit naive - it doesn't "clean out" or see which resources are being used. On the frontend: There's a script that globs all `.graphql` files and compiles them into a list of {query, variables}. This probably could be made better if it was a webpack plugin that compiles this on build time. This was a Friday project so our time was pretty limited. This was honestly good enough since it caught a shitload of bad queries =). Query contains the graphql query. Variables contains test arguments. It saves them into a gigantic file (example: https://gist.github.com/maktouch/074339517a8da5128d62869356b75893 https://gist.github.com/maktouch/074339517a8da5128d62869356b...) On the GQL server: We take that file, we parse it, and we loop it and pass it thru the validate function (https://graphql.org/graphql-js/validation/#validate https://graphql.org/graphql-js/validation/#validate) (truncated example: https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361be28b https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361...) Ops: Frontend and GraphQL are its own Docker image. We build both in parallel. When both succeeds (in building and running their own tests), there's an extra build step that runs this specific test. It does it by taking the gql-queries.json file from the frontend container, adding it to the GraphQL image, and running the validate command. You can do this by doing multi-stage builds in Docker (https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds https://docs.docker.com/develop/develop-images/multistage-bu...). We don't push the resulting image - it's just there for testing.
jwandborg 8y ago
We use apollo-codegen to generate flow types for queries.

maktouch 8y ago

Sure! Our implementation is a little bit naive - it doesn't "clean out" or see which resources are being used. On the frontend: There's a script that globs all `.graphql` files and compiles them into a list of {query, variables}. This probably could be made better if it was a webpack plugin that compiles this on build time. This was a Friday project so our time was pretty limited. This was honestly good enough since it caught a shitload of bad queries =). Query contains the graphql query. Variables contains test arguments. It saves them into a gigantic file (example: https://gist.github.com/maktouch/074339517a8da5128d62869356b75893 https://gist.github.com/maktouch/074339517a8da5128d62869356b...) On the GQL server: We take that file, we parse it, and we loop it and pass it thru the validate function (https://graphql.org/graphql-js/validation/#validate https://graphql.org/graphql-js/validation/#validate) (truncated example: https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361be28b https://gist.github.com/maktouch/e1a2955dfcca42541a41665a361...) Ops: Frontend and GraphQL are its own Docker image. We build both in parallel. When both succeeds (in building and running their own tests), there's an extra build step that runs this specific test. It does it by taking the gql-queries.json file from the frontend container, adding it to the GraphQL image, and running the validate command. You can do this by doing multi-stage builds in Docker (https://docs.docker.com/develop/develop-images/multistage-build/#use-multi-stage-builds https://docs.docker.com/develop/develop-images/multistage-bu...). We don't push the resulting image - it's just there for testing.

jwandborg 8y ago

We use apollo-codegen to generate flow types for queries.