GraphQL Conf 2019 in a nutshell - Some Takeaways
GraphQL Conf 2019 was happening on 20-21 June in Berlin & this is an example of Idea forming huge community. Here are some takeaways from GraphQL Conf 2019
GraphQL Conf 2019 was happening on 20th and 21st June in Berlin and I was lucky to be there to see how an idea can form huge community.
GraphQL was open sourced in 2015 and since then community kept on expanding and approximately 800 people attended GraphQL Conf 2019.
Here are few of my takeaways from this conference. Following are just my opinions and understandings from all the amazing talks presented in the conference.
Data requirements are core reason to build the GraphQL API
- Data Requirements form tree as the data is related
- Server design should be around asynchronosity and concurrency
- Strive for Single source of truth
- GraphQL is a thin API layer which does not address the needs of Auth, Caching, Performance and Rate Limiting
- Resolvers should not contain business logics; rather they should map to the business logic
Clients design can follow following design models
- JSON Model
- Face problems of Typos, Type Safety, Over-fetch and Under-fetch
- Good For Small Teams and small apps with fewer types
- Type Model
- Fixes type safety but Hard to make aliases for some fields
- Grows huge over time
- Needs a lot of testing to keep it sane
- Response Model
- scalable to many teams
- no under fetch as everything is based on what has been asked for
- in long term, becomes a over-fetching in most of the cases
- Fragment Model
- Data Models behave like black boxes
- Good for big teams and many teams
Tooling and GraphQL
- Strong community means better tooling with great documentation
- Well Documented tools make it easy to onboard new developers
- You can and you should build your own tools to make your development flow better
- ASTs are the efficient way to approach the tooling by parsing files to AST and then further operate on the AST to do meaningful operations
Error/Result Handling in GraphQL
In GraphQL, all the errors are not same
Some Errors may be business restrictions, some may be platform and might actually be a real error
Rather use Field Unions to merge different fields. This allows to define and customise the expected field results and hence the errors are more descriptive.
UserResult = User | BlockerUser | UnavailableUser
Descriptive errors means Data being more descriptive and hence we avoid some common business errors showing up as an error
REST to GraphQL
GQL API Design Strategies
GraphQL API design strategies had been the major part of the conference where primary highlight was Code First Design rather than Schema/SDL first.
For past times, the community had been focusing a lot on SDL as it defines attracting benefits of GraphQL like:
- Contract and communication tool between teams
- Easy to get started with API creation
- Fast Mocking
- Highly Declarative etc.
But there are trade offs of SDL like:
- Code Duplication
- Documentation
- Complexity for bigger APIs
- Hard for Microservices
- Lacks Modularity
So, to Fix the problems of SDL and make GraphQL API design more convenient with Code First, two new things were launched on 20th and 21st
- GraphQL Nexus (GraphQL Nexus · Declarative, Code-First GraphQL Schemas for JavaScript/TypeScript) by Tim Griesser
- Photon JS and Lift by Nikolas Burk from Prisma
- Lift: Declarative data modeling & database schema migrations
- PhotonJS: Build & ship faster with type-safe database acces
Though for PythonJS, all it existed was a Code First API creation tool, Tartiflette was introduced by Stan Chollet from dailymotion.
And then there was a session from Bernardo Raposo about How Figma's API can be used to make much human friendly tool with GraphQL.
Then there were some highlights about the GraphQL Migrations where all could be said around the five rules before starting to migrate:
- Is it really needed?
- Do it incrementally
- Manage both systems, old & new, until you are completely done with the migration
- Automation is the key; automate to update your code, testing, reporting etc
- Documentation & Evangelism; document your migration and discuss more about the process and journey of migration
Then on the next day we got to see some Functional Programming from Roy Derks. Roy showed how to make React and GraphQL programs with ReasonML.
It was very clear that typed systems are better to test and manage than non-typed. Take TypeScript, Flow or ReasonML and have the benefits of Typed System in JS.
We got some tips to make our GraphQL API infinitely Backward Compatible.
We learned that there can be many ways where API can fail; like:
- Type Definition delete
- Type Definition change
- Delete Field
- Change in Nullability
- Changing or Un-implementing an Interface etc
And then there were tips:
- Respond to Anything
- Warnings on the Pull Request Builds
- Warning on the Pull Requests Usage with Field Usage Metrics
- Dogfood Eating your own dog food - Wikipedia
- Slow Rollout - rollout to small group of users and monitor
- Get Creative/Improvise
And in the end;
GraphQL Schema Design must be an afterthought
Then we had Kyle Mathews; CEO and CoFounder of Gatsby presenting how GraphQL help Gatsby to take over the Static Sites' world by storm.
Apollo announced Apollo Federation;
Apollo Federation
Apollo Federation is a successor to Schema Stitching which allows Declarative Graph Composition by separating the concerns of entities
Apollo Federation does it by introducing three core concepts:
- Entity & Keys
- Type References
- Type Extensions
Similar to following example where the User
and Product
are extended by Review
# reviews service
type Review {
body: String
author: User @provides(fields: "username")
product: Product
}
extend type User @key(fields: "id") {
id: ID! @external
reviews: [Review]
}
extend type Product @key(fields: "upc") {
upc: String! @external
reviews: [Review]
}
And then the gateway get the config for all the schemas
Later we had an interesting talk by Andreas Marek; creator of graphql-java
about the possibilities of GraphQL execution strategies. He explained the following possible strategies:
- Batch Strategy
- Delegation Strategy (this seemed more or less similar to Apollo Federation)
Then we had a nice presentation by https://twitter.com/email2vimalraj about making highly available GraphQL subscription API
Later in the afternoon we headed towards the conclusion of the conference where Honeypot showcased the GraphQL documentary which you can watch here:
As the closing talk, Lee took us through the journey of internet showing journey of internet's start and growth and how GraphQL came to be a huge Open Source Community driver.
You can watch the Conference LiveStream here: