People today demand a lot from the web and mobile apps. They want an experience that shows a deep understanding of who they are and what they need, that works seamlessly across all their devices, and that magically accomplishes complex tasks with just a click or a swipe. And that experience must quickly and constantly improve.
This kind of digital experience is what defines a company’s competitive advantage, yet most of the product teams working to deliver them are disadvantaged by technology that was never designed to handle these new levels of complexity. In some cases, over 80% of an application’s code (and development effort) is focused on managing and loading the data that makes the experience possible. This is the reason so many organizations are turning to GraphQL.
REST APIs have been the standard for sharing data between applications and services for the past 20-plus years, but they don’t have the flexibility and agility needed to keep up with the constantly growing number of applications, platforms, and services in use today. REST is a procedural API technology that requires developers to coordinate each use case ahead of time. Frontend teams must constantly ask backend teams for new endpoints, often with each new screen in an app, dramatically slowing the development process.
GraphQL solves these problems by enabling frontend developers to request specific information, without backend developers having to predict and define bundles ahead of time. GraphQL provides a description of the data available in an API, and enables clients to ask for exactly (and just) what they need
More and more developers are doing just that: The State of JavaScript, which surveyed more than 20,000 JavaScript developers, found that 83% are using or intending to learn GraphQL.
Indeed, teams evaluating and using GraphQL come from companies of all sizes, sectors, and geographies. They are working to determine GraphQL best practices and how GraphQL fits into other systems the company has invested in — not to mention how it fits with other priorities, from infrastructure to product engineering and beyond.
In this article, my goal is to provide some context and a common language around GraphQL, so that you can make informed decisions — whether you have started working with GraphQL already or are just considering it.
Changing How We “Do” App Dev
Two major and relatively recent shifts have changed the development model.
First, the data that we use when we build applications and the data that we want on the screen is coming from a growing and disparate suite of services, comprising different technologies and built with different sets of considerations. As an app developer, you have to draw different elements from that suite and make everything work together, often in new combinations for each product or feature.
Second, app developers write for many new platforms now. It used to be a big deal to develop an app for the web and for mobile. That concept seems almost quaint today, as developers work to meet customer demand by building applications across web and mobile, certainly, but also across chat, IoT, wearables, virtual reality, Alexa, and so on, and so on.
All of this presents a really big challenge: How are we going to connect all of this data to all of the features we need to build, at ever-increasing velocity?
The answer is fortunately pretty simple: Instead of defining specific APIs to draw data for each of these services to each of those applications — which means writing and maintaining a lot of code — GraphQL works by enabling the service layer to describe the data it has and clients to describe the data they need.
There are many advantages to this model — not least, developers don’t have to write REST endpoints. But the biggest benefit is the changes GraphQL brings to your tooling and your workflow — in other words, the changes it brings to the way you do app dev.
For example, GraphQL is based in “schema-centric development.” The idea is that your GraphQL schema — the menu of all the data you have in your organization — is the anchor for how your frontend team and your backend team rendezvous as they build features. With this “data graph,” developers can seamlessly draw upon a unified, always-up-to-date catalog of all the data available to them as well as the connections between various services. Benefits of the data graph include faster development, consistent user experiences across apps and platforms, fine-grained understanding of application performance and behavior, and strong, centralized security.
Stages to Adopt GraphQL
For most companies, implementation of GraphQL includes three stages — all of which can be rolled out incrementally, on top of existing APIs, so there’s no need for a rip-and-replace approach. These stages are:
1. Validate with one feature.
This is where teams will get a feel for the full development experience.
For a product team, the core of that development experience is the trio of a component framework like React, a data layer like Apollo, and a type system. This new modern stack is transformative, and by rolling out GraphQL to just one feature, you can start to experience why.
GraphQL has the potential to create incredible developer experiences. Thanks to its strongly typed schema and query language, you can bring other tools to life, like your IDE, by enhancing them with rich metadata from your graph API. Imagine VS Code informing you when a field you’re using is marked deprecated in the graph, or that shows the anticipated performance cost of adding a field to a new query, right as you type it.
2. Support an entire product.
The next stage is about putting a key product on a graph — from a few people on a sprint, to several product/sprint teams collaborating on a key part of your product. Dev velocity skyrockets for the product in this phase. You start to see a major reduction in code footprint.
During this phase, you want to keep the schema small and focused on the needs of the product and its users. And you shouldn’t make any significant changes to your microservices. These are your core capabilities — owned by separate teams — and a key part of the data graph adoption strategy is to decouple other teams’ requirements from yours.
At this stage it becomes important to use a graph manager to start tracking and managing the schema — including validating changes. Whether it’s adding fields, changing types, or deprecating fields, developers need to ensure that any change they make to the schema will be validated against a set of rules and coordinated across all the different parts of the stack — not just for your first-party clients and your first-party API, but also for your third parties, your partners, your external clients, and any other entity making use of your data.
3. Leverage data across the business.
As teams get bigger and expand their use of GraphQL beyond that first proof-of-concept app or first feature, developers can explore tools and platforms that manage the use of GraphQL as it scales across the organization. Organizations should look for solutions that will enable multiple teams to rendezvous around GraphQL and implement a workflow that allows them to collaborate in a safe and effective way. Developers should also be evaluating tools for their ability to be seamlessly integrated into the whole development process.
At this stage, you’re going from something that basically one team built to something that the entire organization can share, as a strategic layer of the stack. This is where the benefits of one data graph — and federation — come into play, providing consistency and reusability across the organization in a way that enables everyone to take advantage — even teams that don’t know that much about the graph or all its underlying services.
You start small, and then you expand. For example, the mobile team might take notice of what the web app team is doing and ask to query its graph. And then maybe the adjacent tools team decides to take advantage, and it adds a bit to the graph to support a particular use case. Pretty soon you’ve got something that spans the whole organization.
The challenge is to do this without building a big monolith or a central chokepoint for development because the idea that we’re going to roll out a big GraphQL server in front of every single API you have and behind every single application you ship doesn’t quite add up. There must be a way to do this in a safe and distributed way.
One large global organization we’ve worked with — which includes more than 25 brands, 500-plus developers working across the globe, 50-plus frontend apps and client pages, and 20-plus API teams that power all of the moving parts (flights, bookings, etc.) — implemented a data graph that is distributed across multiple GraphQL services composed together in one graph.
This works by splitting the graph architecture into two layers with separate responsibilities. One layer is a set of services, each of which implements parts of your graph. The other layer is infrastructure that’s shared across the organization: the gateway. The gateway joins everything together, and developers execute queries against it as if it were one graph.
In fact, federation and other tools built into GraphQL — and the ones that are growing up around it — are really what make GraphQL exciting at PoC and viable for companywide standardization.
With the right tools, these things that don’t have an analog in the REST world are possible with GraphQL, no matter where you are in the GraphQL implementation cycle. GraphQL and the data graph model can transform how product teams collaborate — and innovate — across the stack. Finally, with GraphQL we have an API technology that provides a foundation for the kind of constant iteration and innovation companies need to do in order to compete — now, over time, and no matter what changes and challenges are on the horizon.
Feature image via Pixabay.
InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Apollo GraphQL.
