[maktouch]

We deployed our GraphQL July 4th 2016. It'll almost be 2 years. Documentation sucked back then (and apollo was non-existent), so a lot of we had to dig by ourselves.

I hope this book will cover some topics for others that was real head scratchers for us

- DataLoaders

- Authentication example

- Unions and Interfaces are your friend. Use them early.

- Try to define your custom Scalars early (especially DateTime format)

- return Connections (edge/node) instead of List cause you probably want to paginate at some point

- Folder structure (we redid ours 4 times lol)

- Naming convention (we redid ours 3 times lol)

- Subscriptions

After 2 years of using it and hacking it, we're still impressed. Once you get past the learning curves and have set conventions, writing GraphQL is a lot faster and better. Define your types, and some custom root queries, and done.

The neatest thing is that we made a schema validator -- compile all the graphql queries from the frontend and mobile, and validate them against the server schema. It really help when we changed folder structure and naming convention to see if we'd break something on the frontend.

I can't vouch for this book yet, but I'll swear my life on GQL. It's been a real game-changer.

[cpursley]

For what it's worth, if your stack is Elixir/Phoenix (or if you're considering that stack), I can't recommend the following book enough (it covers the topics you mention).

https://pragprog.com/book/wwgraphql/craft-graphql-apis-in-el...

A nice thing about this stack is it supports the GraphQL Subscriptions protocol out of the box without the need to set up a separate pubsub server.

[asphyxiac]

+1 for this book. This tutorial by one of the authors is great introduction to the Elixir gql stack: https://www.howtographql.com/graphql-elixir/0-introduction/

Worth a try if you’d to learn more about the stack or the author’s pedagogic style before buying the book.

[misschresser]

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]

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.

[jwandborg]

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

[dev1n]

Regarding folder structure, we developed saturn-gql [1] to help out with that. Have a look if you're still battling this.

[1]: https://github.com/electric-it/saturn-gql

[maktouch]

Hey, that's cool! Thanks for that, will try it out on a new service/pet-project one day.

In our current service, I think we're pretty happy with the way our structure is. It's almost similar to saturn-gql but with raw javascript instead of parsing with `graphql-tools`.

[skybrian]

I'd love to read more about this. How did naming conventions and folder structure change?