GraphQL Summit 2017: Day 1
I thought I knew a lot about GraphQL. The patterns and concepts are all too familiar, but that’s much like learning syntax. What I didn’t know was the complexity of maintaining a “simple” GraphQL schema to scale. Today I got to see examples of GraphQL in the wild, full throttle. The beauty of its potential is that it’s limited to the confines of typed data. If you can imagine any dataset — so can GraphQL.
If by some circumstances you don’t know what GraphQL does — here’s my best metaphor:
GraphQL is like watching the recap on a TV episode to figure out exactly what you need to know to continue instead of watching the entire episode. Clients declare a dataset they need, and the server returns that and only that. No more or no less — GraphQL is a contract. It’s like when you go to a restaurant — you get exactly what you order instead of the entire menu. Call it the REST API killer.
Day 1 of my first conference was thrilling. With so much talent in one room, it’s hard to describe exactly what to take away — other than everything. Some of the juicy bits I picked up:
GRAMPS (GraphQL Apollo Microservice Pattern Server)
This awesome Express middleware lets you compose a schematic for your data layer that is made of multiple data sources. Each data source can exist as it’s own packaged and imported in the runtime.
This pattern is a great way to look at code ownership — where each team can publish it’s own data and the data layer can stitch it together automatically. Jason Lengstorf of IBM describes this pattern in a way that suits microservice architectures and really opened my eyes towards a pattern of how to shard a schema.
I could go on about why I love this pattern but I will end on what Jason describe’s as the future of API: open public data sources. Imagine publishing your data as a GraphQL package.
Apollo however has made some profound advancements. Backed by Redux — the developer tools let you trace every state change and travel between mutations. The Launchpad let’s a developer bootstrap and mock an API without needing a server.
What I enjoyed most in this talk was James Baxley III and how he describes the use of GraphQL as a vehicle for fetching REST APIs. If you want to co-locate and batch your requests, why not use GraphQL as a function of querying multiple sources? Here’s what that looks like:
In this example, a REST API is queried without having to issue multiple network requests. The client can use GraphQL solely in facilitating data gathering — and reference values in further fields.
If by now you are still rooting for REST — I have a bridge to sell you.
Wait. There’s more…
In no particular order, here are some other juicy tidbits that have captivated the interest of today’s summit:
- Error handling using uniquely identifiable traces and metadata. By normalizing errors there’s a tight integration between user experience and support that allows developers to respond precisely.
- Lightweight Querying is so often overlooked when choosing a library. When in GraphQL we tend to pull a hammer out of our toolbox by going immediately to Apollo or Relay. New abstractions are being considered instead of plain old AJAX.
graphql-requestin particular is of interest when looking for a minimal framework for issuing queries and mutations.
- Persuading your colleagues to use GraphQL is difficult because it’s one of those things that’s hard to understand until you do it. It’s an acquired taste- and once you drink the Kool-Aid you’re left wondering why haven’t we been doing this all along. For those that are unfamiliar or stubborn — hack something together and demo it.
Your first conference is unforgettable. I wish I had not waited so long and had taken the initiative sooner. I am lucky in that the work I do is one in which self-improvement thrives. Challenges are plenty and opportunities are everywhere. When you move to the Bay area, you are surrounded in this bubble of tech and comfort. Problems are simply a matter of engineering and economics. Having this opportunity is incredibly humbling.
GraphQL is slowly on the rise and is heading towards becoming a staple in the data layer. As described today, it’s nature of client-driven development is what gives it an edge. It started as a way to declare data models, evolved into a language that supports fragments and mutations, and has adapted at the pace of the needs for front-end. Client-driven development in recent years has become the focus as we see more of the web traffic go through mobile.
If you are hesitating to go to a conference, I urge you to be impulsive and dive in. It’s an eye-opening experience. Opportunities like these do not wait for you to be ready, and you don’t need to be a master of the trade to discover the potential. Even if you are the master of your field — either you’re speaking or you’re acquiring a new perspective into the matter.
Tomorrow I look forward to the day 2 of my first conference. Much thanks to all the admirable talent that have made this possible. Together let’s deprecate every REST API in peace.