GraphQL First: A better way to build modern apps
Over the past few months we have had hundreds of conversations with developers who are excited about GraphQL and using Apollo in their projects. From products like GitHub moving to public GraphQL APIs, to enterprises telling us that GraphQL will be mission critical for them in 2017, GraphQL seems poised to be the next big trend in app development.
A particularly interesting pattern seems to be emerging. Over and over again, I hear developers describing a way of approaching product development we’re calling “GraphQL First.”
When you build modern UIs directly on REST, you’re stuck writing lots of imperative code — either client-side code that filters, joins, and transforms the data coming from REST endpoints, or feature APIs on the server that support each screen of each client. Either way, you’ve tightly coupled your UI to service code, encoding the specifics of how they work into each other. Product development bogs down because so much time is wasted writing and maintaining that fragile data-fetching code.
The anchor of GraphQL First is the schema, a contract between your UI and services that keep them aligned but fully decoupled. In a GraphQL First architecture, you write declarative queries to feed your UI instead of writing imperative code to juggle data between your services and UI. With that strongly typed and self-documenting schema in place, each UI component, product feature, and service endpoint is self-contained. You can build them all in parallel, developing and testing each piece against mock data automatically generated from your schema, and then assemble it all together at the end.
It’s also easy to incrementally bring a GraphQL First architecture into existing apps. The trick is to start with a small schema — just enough abstraction over your backend to power a single UI component. From there you can expand component-by-component, client-by-client, service-by-service until you’ve transitioned everything over. There’s no risky cutover or big architectural leap, just a smooth migration and expansion of your schema as you transition from code to queries.
Working with GraphQL for over a year, we’ve been asking ourselves what we can do to improve the technology, move the developer community forward, and be the company that helps teams adopt GraphQL.
Part of this effort includes hosting the GraphQL Summit, the world’s first GraphQL developer conference happening this week in San Francisco. The sold-out event features the who’s who of GraphQL including speakers from Facebook, GitHub, Credit Karma, and Shopify. Over 350 developers from around the world are attending to share their experiences with GraphQL, contribute to open source projects, and shape the next chapter for GraphQL. If you couldn’t make it to the event, we’ll be posting video replays in coming weeks.
We’ve also been hard at work on a set of tools and libraries for GraphQL that I’m excited to share today. Each of these is 100% GraphQL compliant: you can mix and match them with other tools from the community any way you like. At the same time, they are designed to work especially well together, adding up to a great GraphQL developer experience. Most importantly, everything we’ve done has been hand-in-hand with the community and built to solve the real needs of modern apps.
The 0.5.0 version of Apollo Client includes everything you need to put GraphQL in production: a tight integration with Redux and its developer tools, a fine-grained client-side cache, and clean APIs for pagination and mutations. We’ve also worked hard to provide great documentation and example apps that make it easy to get started.
We’re now looking ahead, working with the community on what’s next for production GraphQL. For example, we have already released a first version of GraphQL subscriptions, and we are working with developers on persisted queries and static type generation for TypeScript and Flow. Over 100 developers so far have contributed to these and other features in Apollo Client, and we’re excited to working with teams using GraphQL in production to make it even better.
We’ve also got exciting news for native mobile developers: we have shipped a first release of Apollo iOS, our first native mobile GraphQL client. Mobile is where GraphQL truly shines; in fact, GraphQL has powered Facebook’s main iOS app for over four years. GraphQL, with its strict type system, fits perfectly with modern mobile development practices.
Apollo iOS, written in Swift, returns results as query-specific Swift types. When developing with Apollo iOS, Swift type checking will validate queries and flag data access errors at compile time. We’ve included a tight integration with Xcode, so that you can conveniently work with your UI code and corresponding GraphQL definitions side by side, see errors inline, and even autocomplete fields in your query code based on the GraphQL schema.
At the heart of the iOS client is apollo-codegen, an open source tool we’re working on for generating typed models from GraphQL. We’re using it for Swift types, as well as for the TypeScript and Flow support mentioned earlier. And a community effort is now underway to add support for Java types, the first step on the path for an upcoming Android client.
The other thing we’ve heard over and over from developers using GraphQL is the need for production-grade instrumentation. GraphQL’s fine-grained queries open the door to measuring and understanding API behavior in ways never before possible.
So today I’m especially excited to announce Apollo Optics, the world’s first tool for getting insight into GraphQL APIs. Optics helps you understand the behavior and performance of your GraphQL queries, including a graphical field-by-field breakdown of each query’s cost and how it’s assembled. You can use Optics to monitor overall API usage, track which GraphQL queries are hitting your server, identify performance hotspots, and detect trends or changes in API workload.
Because GraphQL clients query the exact fields they need, Optics can show you how your data is used all the way down to the field level, giving you insights that aren’t possible with REST APIs. For example, you can you use Optics to coordinate field deprecation, identify clients that would be affected by a schema change, validate proposed server changes against your real-world workload, identify parts of your API that are underutilized, and focus optimization efforts where they have the biggest impact.
Apollo Optics supports all GraphQL clients, including Apollo Client and Relay 1. Today, Optics has production-ready support for every Node.js GraphQL server, with beta support for Rails available too.
We’ve been in early access with Optics with dozens of customers for several months, and it’s helped them answer tough, GraphQL-specific questions where traditional tools fall short. According to Daniel Rinehart, a software engineer @ Philo, “Using Optics, my team was able to pinpoint areas to improve our GraphQL performance.”
You can try Optics for free starting today, no credit card required. Learn more and sign up using your Github ID.
Training and support
In concert with delivering open source and commercial tools, we’ve also begun helping companies train their developers and accelerate their GraphQL projects through focused technical support. As part of the GraphQL conference, we held a GraphQL training workshop in collaboration with OK GROW! If you have tough questions about your GraphQL implementation or a development team you’d like to get spun up, we’d love to see how we can help.
Growing the community
As we look towards 2017, we’re excited about where the GraphQL community is heading. Many of you have already contributed to open source projects, promoted GraphQL in talks and online, and shared your best practices on our Slack group. Great tools, events, and content are only possible with the help of the community so we can’t wait to see where your ideas and energy take us next. And if you’d like to work on GraphQL full-time, please consider joining our team!