Leave the API Plumbing Behind – InApps 2022

GraphQL tooling provider Apollo has released Apollo Client 3.0 in what it says is the culmination of a year’s work, combining 55 betas, 14 release candidates, and hundreds of resolved issues and merged pull requests. Apollo Client is a state management library for JavaScript that enables developers to more easily manage both local and remote data with GraphQL.

The standard elevator pitch for GraphQL usually offers a blanket comparison between REST APIs and GraphQL, wherein the latter provides the ability to make customized queries and get specific results, rather than simply querying an API and getting all of the data. The value proposition is simple: GraphQL offers a more efficient, customizable, and client-side API experience for developers, but Matt DeBergalis, chief technology officer and co-founder of Apollo, explained that Apollo Client 3.0 really simplifies the developer experience by handling all of the glue code they would otherwise have to write on the client-side.

“In many ways what React did for UIs, what Docker and Kubernetes do for running services in the cloud, that’s what Apollo does for your API: It brings structure to it so that you can focus on the specifics that have to do with your app and your data and leave the plumbing and the complexity to the system as a whole,” said DeBergalis. “App developers are adopting GraphQL because it allows them to get out of the business of writing a lot of boilerplate and plumbing code to connect the data they have to the user interface they’re trying to build.”

Estimating that Apollo Client accounts for “probably 95% of all of the use of GraphQL in the market,” DeBergalis called Apollo Client “the industry standard for how you connect user interfaces on the web to GraphQL APIs,” explaining that while developers initially adopt GraphQL for those aforementioned benefits, they stick with it due to those devils in the details that Apollo handles for them. Some of those details are addressed with the release of Apollo Client 3.0, such as help with pagination, improved local state management, and the introduction of reactive variables.

“The job of Apollo Client is to keep all of the data on your screen up to date and in sync. If you change one part of the screen, Apollo Client, behind the scenes, makes sure that all of the other data that’s related to that is also refreshed,” said DeBergalis. “If you think about long lists that you have to paginate, if you think about real-time interfaces, where information changes as you’re using the application, all these kinds of patterns are what every application development team is off building by hand with code every day and Apollo Client 3.0 is what bakes all of that into a library so that developers can use that off the shelf and just type the description of how they want the app to behave.”

Apollo Client 3.0 introduces an overhauled cache meant to be more flexible and performant, with new features like garbage collection, a new cache policies API, and the ability to store both normalized and non-normalized data. Reactive variables, meanwhile, provide this behind-the-scenes updating by registering a dependency when you read it, and later triggering a rereading whenever the value is updated.

“Reactive variables are all about state management. It’s a programming pattern and it’s a way of being able to really concisely describe that there’s a piece of data that may change. I don’t want to have to write code to update my screen when that data changes. I don’t know when that data is going to change,” said DeBergalis. “It’s a pattern that lets teams decouple their work, so that a team that’s responsible for one part of the UI can simply describe, ‘there’s a piece of data I care about’ and when it changes, I want to be able to update this piece that I’m implementing in the UI and I don’t have to understand how my piece is fitting in with all the other parts of the user experience that other teams are responsible for.”

Looking ahead, DeBergalis said that federation was something the company would be focusing on and talking about quite a bit at its upcoming GraphQL Summit. The company has already introduced a product for the federation, Apollo Federation, last year, but it focused on federating across teams, not companies. Where Apollo is looking next is taking that same idea and expanding it across separate companies.

“At Priceline, for example, they had one team building a GraphQL API for flights and flight search, and another team building a GraphQL API for rental car search. It turns out at the end of the flight search process, when someone buys an airplane ticket, you want to sell them a rental car, but combining those two is challenging. So, they’ve adopted federation as a way to be able to just write the obvious feature that they want, where there’s a part of the application that draws from both of those data sets,” said DeBergalis.

Feature image by Archer Mechanical from Pixabay.

At this time, InApps does not allow comments directly on this website. We invite all readers who wish to discuss a story to visit us on Twitter or Facebook. We also welcome your news tips and feedback via email: [email protected].

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Docker.