A Case for GraphQL in Enterprise
A Case for GraphQL in Enterprise
GraphQL is a promising, battle-tested technology that holds the key to solving key challenges in the enterprise IT space, specifically in accelerating API/app development cycles.
Join the DZone community and get the full member experience.Join For Free
GraphQL supports dynamic queries and is type-safe. This reduces the number of APIs to be developed and allows enforcing compile-time checks on the data being requested by consumers.
It was designed to be able to seamlessly front multiple sources of data, reducing the number of complex, cross-functional API dev iterations.
- It is backed by an active community that is constantly improving the tooling and simplifying GraphQL adoption.
APIs in Enterprise
Gartner positions APIs at the forefront of Digital Transformation or similar CIO initiatives. Sharing data-driven insights and building efficient workflows to deliver value to stakeholders largely entails building and managing APIs for applications.
GraphQL, a query language specification developed and open-sourced by Facebook, is rapidly revolutionizing the API Lifecycle Management (APLM) space. To understand how GraphQL adds value here, first, let’s take a brief look at the typical phases of APLM:
Design, Development, Testing, and Deployment are self-explanatory. The phase “Retiring” refers to the stage when an API needs an upgrade or has to be deprecated.
GraphQL and API Lifecycle Management
GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn’t tied to any specific database or storage engine and is instead backed by your existing code and data — https://graphql.org
Here’s a side-by-side comparison of GraphQL and REST versions of APIs for two sample use-cases:
Using GraphQL to publish a dynamically queryable and typed schema is the same as offering a strongly enforceable contract to the consumers of your API that can be validated at compile-time using client-side tooling. This reduces the scope for run-time errors! It is important to understand this and the source-agnosticism mentioned above — most of the arguments in this post to make a case for GraphQL in Enterprise will follow from them.
Let’s use the same examples as above and take a look at how API Lifecycle Management phases are affected by GraphQL:
One of the major problems with REST APIs is that the fields to be returned has to be predetermined at design time, with no room for implicit flexibility. Need a new field from your REST API? It needs to go through a fresh iteration.
In the case of GraphQL, design equals establishing the scope of data that needs to be “exposed” (anything within that scope can be queried). So in our example, the schema for authors, articles, and their relationships needs to be published. Achieving this kind of flexibility without GraphQL implies dumping a superset of data for every request at the cost of performance!
Authoring a GraphQL API involves a one-time effort of writing a GraphQL server and defining and implementing the GraphQL schema. The ecosystem is ripe with tools that handle most of the heavy-lifting (For e.g. Hasura provides a ready-to-use GraphQL server that automatically infers the schema from a database and handles the underlying implementation). If the schema remains unchanged, there is zero incremental cost to get any API that interacts with just these two tables — the API in the 2nd example comes free with the first one! This is obviously not the case with REST APIs. So, not only is the cost of a new REST API orders of magnitude higher compared to GraphQL, the cost of a marginally different REST API remains the same.
Moreover, GraphQL APIs can be:
- leveraged to make a single nested query as opposed to writing and using multiple REST APIs
- queried as needed with server-side transformations instead of having multiple variants of the same query or delegating this to clients
- Used to auto-generate client-side code
GraphQL brings a lot of other magic to the table to improve a developer’s experience of building and iterating on APIs:
Multiple data sources: An important use-case in the Enterprise space — data from different sources, especially legacy apps/DBs, is often required to be queried together. This is usually a technical and an operational nightmare (in every iteration). Here’s an anecdote from James Baxley (Apollo GraphQL) from his experience at a $64M Enterprise:
“We wanted to use the Meteor accounts system and reactive data, get financial accounts, show giving history, and show profile info from Rock, have all of our images and content stored in our CMS, and we wanted in-app search using Google’s site search API. That sentence is just as exhausting as it would’ve been to build those endpoints using REST!"
James and his team at NewSpring Church used GraphQL because a GraphQL API can be supported by multiple sources of data by stitching their schemas together. More often than not, this will be a one-time effort, saving the need for expensive cross-functional operations.
Interface for multiple data sources
In one week, a single developer from the NewSpring team was able to connect all of those databases and systems together into a single endpoint.
API/Schema discovery: What’s the equivalent of Google and 3rd party documentation inside an Enterprise? Internal documentation and wikis are not the answer — the average rating by developers for internal documentation is 2.3/5.0. With a published schema, GraphQL has API discovery or documentation implicitly built into the server with tools that take advantage of this.
A GraphQL IDE using the schema for auto-suggestions and validation(graphql.org)
Standardised code and workflows: Working with a specification like GraphQL enforces a certain amount of standardization in codebases and processes. Considering the attrition rates in IT, this is a surprisingly underrated benefit of GraphQL.
Testing and Deployment
It follows from the above that GraphQL APIs need to be tested only when there’s a change in the schema or there’s a fresh schema (the client still needs to be tested). This also holds true for deployments. Given the imperative nature of REST APIs, every iteration is a candidate for testing and deployment. As with development, the cost of testing and deploying REST APIs is significantly more expensive compared to GraphQL.
Another area where GraphQL outshines REST is in its ability to reduce run-time errors and related testing due to its typed schema. Client-side tooling/SDKs to exploit this benefit and provide compile-time client-side query validations is the norm in the GraphQL ecosystem.
Query validation in an IDE
API versioning is traditionally the route taken to evolve or deprecate REST APIs. However, this exercise is difficult without the exact knowledge of how APIs (or more accurately, the attributes/fields in the response) are actually being used. With GraphQL and its typed schema, tracking the exact usage of all the “elements of the graph” is possible.
It is important to note that GraphQL is not a substitute for existing paradigms (REST) but a complementary one. There is plenty of balanced online literature that helps organizations make this choice and safely navigate their GraphQL adoption journey. First-time GraphQL backend developers also face a fairly steep learning curve in the early days. This and a few other rough-edges like caching, granular access-control, etc. have been identified and are being actively addressed by the community and service providers.
GraphQL makes a strong case for being a crucial tool in an enterprise developer’s armory. It also helps that the backing of a vibrant open-source community brings a rich collection of tools and a plethora of managed services catering to developers and Enterprises.
It is, therefore, not surprising that GraphQL is seeing widespread adoption across a diverse set of industry verticals, from technology companies (Intuit, Coursera) and media giants (The New York Times, Condé Nast) to a cancer research hospital and a church (most of these Enterprises are also active contributors to the community). See this list of popular GraphQL users.
Opinions expressed by DZone contributors are their own.