Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


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/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)

(truncated example: 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-bu...). We don't push the resulting image - it's just there for testing.


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




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: