Apollo GraphQL this week updated its namesake GraphQL client software that among other things improves performance using in-memory caching application programming interfaces (APIs).
GraphQL has emerged as a popular alternative to REST APIs because it provides developers with a query engine that provides more control over what data is requested. Similar in concept to SQL, developers GraphQL also makes it possible for developers to describe the data they are exposing via an API.
Finally, GraphQL APIs are organized in terms of types and fields rather than endpoints. That allows developers to organize APIs within a graph that makes them available via a single request rather than requiring every communication between APIs to occur on a point-to-point basis.
Apollo GraphQL has created client software that allows developers to employ GraphQL to both query external data in addition to making use of a graph to catalog the services made available within the front end of an application.
Version 3.0 of Apollo GraphQL client software addresses a caching limitation that stems from the fact generic HTTP caching doesn’t work with GraphQL. Every time an HTTP request is made for slightly different data the cached value is invalidated. When the Apollo GraphQL client fetches data from your server it caches that data using a normalized structure that matches the Apollo GraphQL schema, which allows it to locally reconstruct a subset of the back-end data graph. The next time Apollo Client queries any of that same data it can fetch it directly from the cache.
Developers can now also define a field policy for any GraphQL field that appears in your cache. A field policy can include a read function that customizes what occurs when the field is read from the cache and a merge function that customizes what occurs when it’s written.
Apollo Graph CTO Matt DeBergalis said by defining all of this custom field logic in one place developers can avoid repeating code. Other developers can also interact with the types and fields without needing to understand how they’re stored or fetched, he said.
Version 3.0 of the Apollo client library also now includes support for a reactive variable value that registers a dependency when read.
Originally developed by Facebook, GraphQL is gaining a lot of traction on backend systems because it allows developers to describe the data that can be accessed. However, because it also makes it more efficient to query data it’s also now being more widely deployed on clients as well. It’s not clear to what degree REST APIs might be replaced by GraphQL, but at the very least reliance on REST APIs in new application development projects is likely to decline significantly.
The implications of that transition for DevOps teams are significant because the overall performance of applications that rely on GraphQL versus REST APIs should substantially improve. In fact, the biggest inhibitor to GraphQL adoption at this juncture may be simple inertia. Too many developers simply build REST APIs as a matter of reflex without necessarily investigating alternatives. However, it should not be too long before everyone on the DevOps teams starts to appreciate just how much the end user experience really is when GraphQL is employed.
