Key takeaways from GraphQL Conference @Berlin, Germany

This article has been originally posted on my Medium account here

Day 1

Below are my takeaways from Day 1 of the GraphQL conference which took place in Berlin/Germany. Amazing talks by fantastic speakers!!

Dan Schafer’s talk — GraphQL before GraphQL

Everything has to be coded to be async — even when you think it’s not needed to be async, still make it async.
Resolvers have to be async

1. GraphQL was never meant to solve for Authorization, Caching of results, below, rate Limiting when it was developed

2. Resolvers should be thin and should only map to business logic and not contain actual business logic

Sashko Stubailo explained how easy it is to build custom GraphQL tooling for specific use-cases

1. Write tests with less boilerplate code and ability to write custom overrides for testing edge cases, error states using this graphql-tools. Read more here.
2. Preventing a breaking change by checking if a GraphQL field is being referenced or not. Read about it here

Sasha Solomon talked about the errors array in GraphQL response and how to deal with them in a better manner.

1. All errors end up in the errors array, but not all errors are the same.

2. Some of them are real errors like server not available, bad gateway but others like might just be ‘alternative results’ like a blocked user, suspended user, etc.

3. To differentiate errors like above, use union types and basis the type in response, the client can decide what to do.
   union UserResult = User| IsBlocked | Suspended

The key thing is not to create too many types and keep it only to important ones.
This talk was easy to grasp and implement at the get-go :)

Best Practices around migrating to GraphQL

1. Think about making incremental changes, edge cases and ability to safely rollback
2. Build adaptors for easy migration Automated test suites are super important to do this herculean task

Marc-André Giroux’s talk about distributing schemas in GraphQL

1. Always ask the question if distributing schemas is really necessary?
2. Schema stitching helps us achieve schema distribution but business logic often leaks into the API gateway and it ends up being more complex than just simple “proxying” Ideally an API gateway should be like below:
3. Decouple” the clients from the “services” involved in the use cases
4. Avoid domain logic
5. Schemas should be easy to import in the gateway Talk slides here.

This was my attempt to write down what was captured in my notebook and brain :D
I will be writing another blog post about learning from Day 2. Stay tuned!