Key takeaways from GraphQL Conference @Berlin, Germany
Day 2
Day 1 was amazing (Read here if you haven't already :) ) but Day 2 got even better. Continue reading for key points from my perspective from Day 2 of the GraphQL conference
Nikolas Burk’s Code-first GraphQL Server Development with Prisma
Nikolas spoke about Photon, Lift — new tools being launched by Prisma and reasoning for code-first development.
SDL First/Schema First
This is one way of developing with GraphQL where the schema is manually written and then resolver functions are implemented.
- Schema First is very popular as it has a lot of advantages. Schema is the priority which is easy to understand and becomes a medium of collaboration between frontend and backend teams.
- Problems with this approach are the reuse of schema, keeping schema and resolver implementation in sync. SDL is typically represented as plain strings in programs which means the absence of build-time error checks.
These issues and others are solved by amazing tooling that’s available.
Code-first/resolver-first
It is a process where the GraphQL schema is generated programmatically.
- Nikolas mentioned that Code-first helps eliminate all problems of Schema First.
- It automatically brings in type safety and all goodness of SDL first without additional tooling.
The only tool you need is your programming language
I feel this article from Prisma explains both very well. I am going to read more on Code-First :)
Infinite Backwards Compatibility by Adam D. I. Kramer
He elaborated on how Facebook makes changes to a massive schema by making sure it’s backward compatible.
What are breaking changes?
1. Deletion of type/field
2. Change of a field type
3. Removal of an enum value etc.
To solve for breaking changes —
1. Have an automated system in place to check for breaking changes like Introduce PR checks to check for usages.
2. Do a slow rollout instead of releasing to all clients at the same time.
James Baxley III’s talk about Apollo Federation
Apollo Federation is the evolution of schema stitching and a way of writing distributed graph and works with below 2 components:
- A gateway to compose the complete graph and execute federated queries
- Federated services, which are standalone GraphQL APIs.
Federation’s one of the principles is that code should be separated by concerns and not types.
1. Each service builds schema about what it knows the best.
2. The gateway then creates one schema combining all the schemas and has a query plan to decide which service to use based on the client’s query.
Read more here. This is definitely something which I would read more about.
There is a OneGraph GraphiQL Explorer which lets client select fields they want to query instead of having to write them in GraphiQL. Check it out here: https://www.onegraph.com/blog/
The conference ended on a fantastic documentary on GraphQL which can be viewed here.
It was so overwhelming and cool to see how GraphQL came into being and the journey so far.
Conferences are an amazing way to learn about new things related to a particular topic and meet people with a similar mindset and learn from them. It brings new perspectives and helps break the monotony from daily activities.
And what is surreal is meeting the creator of GraphQL — Lee Byron :)
Thanks for reading so far !! :)
