GraphQL: A Long Term Play for Enterprise

With all the buzz around GraphQL and its benefits to developers, it leaves many non-developers wondering about the benefits to an enterprise. Getting funding for technology can be a rough go in many medium-to-large-sized companies. The promise of the most impact with the least cost is usually the one that wins the battle for the funds.

This is exactly why many larger organizations have the idea of “currency” projects and many of them come up at the last minute. Essentially, we look to extend the timelines of a technology until it officially comes to an end of life. Usually, the technology will go through phases of deprecation, containment, or other stages within a technology lifecycle depending on your organization. Regardless, if you’ve been part of one of these projects you know that timelines are very accelerated.

If a company has the budget to spend on improving their existing systems or re-platforming an app from old technology to a new one with no improvement, which do you think they will choose? The term Digital Transformation comes up a lot to highlight a company’s push to increase their digital capabilities through reinventing and re-platforming key pieces of their business. It’s important to remember that there are many facets to a transformation like this where some components can majorly increase business function and others just need to be moved onto a newer technology for reasons like decreasing cost of ownerships or security issues with the current platform.

So where does GraphQL fit into the Digital Transformation agenda? This is a question I have asked since I was first introduced to the technology. I’ve had to dig hard to bridge beyond the developer-centric ideas of what the technology could do and focus on how, if I needed the funding, I could justify to the business the need to adopt this cutting-edge tech.

Most architectures right now are heavily dependent on SOAP and REST services. This pattern is deeply ingrained into modern enterprise architecture to the point where APIs have become so ubiquitous that enterprise developers spend a large chunk of their time there. Some would say that there are so many of these APIs floating around that there is an “API problem”. Every time we needed a new functionality, big or small, we just created a new API. We may even have the same data available through multiple APIs, give or take an extra field or two.

The premise of GraphQL is to achieve a unified data graph, a single source for all data. Imagine that you can have a single endpoint to access data across the entire organization. No more new APIs, just one source to quench all of your data needs. What an inspiring thought for all of those in the world of software development, wrestling with API overload.

The problem I have seen is that if you aim to swap out your REST and SOAP services with GraphQL, there are a few deeper questions to answer:

• If we swap out the current API for a new GraphQL API and the app behaves exactly the same, where are we showing business value to get project funding?
• Do the current services still need to stay in service, essentially leading us to support yet another service?
• Does GraphQL allow us to develop apps more quickly in a large organization?

When reviewing a proposal to bring GraphQL into an organization, these are exactly the questions I would be asking. Likely, if you’ve tried to bring GraphQL in, your business has also asked you these questions. After a while of being immersed in the world of GraphQL, I’d like to give you some insight into how to reframe the adoption of GraphQL as a win for your organization by answering the questions above.

The “like-for-like” swap out of existing APIs for GraphQL

To the business side of your organization, “like-for-like” rewrites likely seem like a money pit that they would rather do without. I’d agree that even as a developer they can be among the most boring projects to tackle. No new functionality, just reverse engineer the current application to work on the new target platform.

The key here is to remember that these types of projects are like upgrading your car. Yes, your old car will get you from point A to point B just fine, just like your new car can. The new car likely gets better fuel economy, better safety, and other more modern features that make it a better choice. If you only look at the function of driving from point A to point B, then yes, both cars are identical. Look beyond that and it’s easy to make a case as to why the new car, although more expensive, does offer greater value than your old one.

GraphQL is like a new car when compared to your older REST or SOAP services. You will be retrieving the same data and doing the same operations but there is a long-term strategy that comes into play. Most of these are long-term benefits but they can pay massive dividends.

One of these benefits is that GraphQL will allow you to augment the app more easily later. If new data needs to be consumed or mutated within the app you won’t have to worry about creating a new API, just simply pull the data from the existing GraphQL API. The front-end team no longer needs to wait for a new API to be built or converse with another team who owns the API they need to use. They can now simply just get that data.

Another benefit is a reduction in complex legacy code which calls APIs to retrieve or mutate data. In many of these legacy apps, there are multiple calls to fetch or manipulate data that may be boiled down to a single call. This means a reduction in lines of code, complexity, and makes the application easier to support. Instead of troubleshooting multiple cascading calls we now have a single point to focus on, the GraphQL endpoint call.

To put this in perspective, if we have a banking application that retrieves the account info for a bank account we may have to do the following REST API calls to retrieve the data we need. It would look something like this:

1. Call the customer API to retrieve customerID based on username.

2. With customerID, call the accounts API to retrieve the accounts for the customer.

3. With the account number, retrieve the account info for that account.

Each of these APIs may be owned by a different team, have different security mechanisms in place, and requires the developer to know which APIs to call to retrieve the info they need. These are also three distinct APIs that require their own infrastructure, support, maintenance, and testing which come with their own costs.

With GraphQL, all of this data could be retrieved by just passing the username to your GraphQL query. In the results you could specify all the data you require from a single call and the GraphQL service knows how to resolve all the data you need, in the format you requested.

So, what does this mean for the business?

• Reduced code complexity means a reduction in support costs and less time to determine the root cause of API-related issues.
• Reduced infrastructure costs since APIs can be consolidated into a single API interface, compared to multiple.
• Exposing this application’s data through GraphQL means that other applications can more easily use that data if ever required now or in the future.
• Reduced testing costs since API testing is resolved to a single interface.
• Ability to easily extend application functionality in the future without having to build new APIs; GraphQL can expose the needed data without requiring a new API build.

These are just a few benefits that come to mind when focusing on “like-for-like” rewrites of existing applications. For new applications or old applications that are being extended, these, plus many more reasons, apply to adopting GraphQL.

Transitioning to GraphQL while supporting old services

If you’ve been around for a few years, you’ll likely recall many migration projects taking place within your organization. Some projects have to be slowly rolled out and others can only be done with a “big bang” approach.

APIs can technically fit into both of these approaches. There are times when a replacement API may be built and consumers may be onboarded to it as time and funding permits. There are also times when an existing API may need to be shut off and replaced immediately in a “big-bang”, all-or-nothing fashion. Scenario two seems to be less common in modern times.

Since we generally tend to do phased rollouts, this means that much of the time we have existing technology co-existing with our old technology. This can mean that the transition can be costly because we are now supporting multiple services achieving the same thing.

This is nothing new and happened when organizations began the shift from SOAP to REST. Unfortunately, some applications got left behind and those SOAP services, meant to be replaced, still exist. It’s not optimal but it is the reality of the situation in large application portfolios, where pieces get left behind.

The shift to GraphQL will hopefully be more successful in retiring these old services. Since SOAP and REST are similarly less flexible than GraphQL, it may have been hard to justify moving an application over to a new service for the same result. There are a few tactics that can help the transition happen more smoothly.

If consuming applications are not ready to move to GraphQL, instead of continuing to run the legacy service as is you may choose to engineer it to leverage the new GraphQL implementation. Effectively adding a REST or SOAP facade that uses GraphQL. This will keep the existing consumers of the service content while reducing complexity in the backend. Then as consumers are ready, they can be onboarded to GraphQL, and eventually, these facades can be decommissioned. There are even tools in the GraphQL ecosystem that can make this extremely easy to accomplish.

Consumers that are still insistent on using the legacy REST or SOAP APIs may also just require some education, much like what we covered above, to explain the benefits of adopting GraphQL in order to push things over the line.

Regardless, even though some of the legacy APIs may need to stay in service, you could port them over to use GraphQL for the data functions within them. If that’s not possible, slowly deprecating your APIs and forcing users over to GraphQL may be the only path. Long term, you know that the benefits of GraphQL will outweigh any harsh feelings on being forced to make the move.

All in all, keeping existing services in play while moving to GraphQL is likely necessary if you are using a phased approach to moving clients over. GraphQL gives you more flexibility than past experiences of technology transformations and allows you to still use it to power your existing services in the background. Short-term costs may be increased due to supporting multiple technologies but as you shift over entirely, costs will continue to go down and development speed will increase. As data becomes available through your GraphQL API, many applications will gladly adopt it without any incentive or deprecation warnings of existing APIs. The goal of getting down to a single GraphQL service would be followed by an extreme reduction in the cost of ownership, now bundled into a single API.

GraphQL as the key to faster software delivery

When developers like a technology it’s usually for good reason. There are always new technologies with great promises being flashed in front of us. Developer productivity has many angles including simplifying developer tasks and deployments by focusing on DevOps, adding lots of plugins to our editors and IDEs, or the newest framework or platform which aims to make building applications faster and better.

Much of these are empty promises. The ability to deliver software quickly usually comes down to a few things, mainly:

• Quickly resolved dependencies (including access to data through APIs).
• The ability for developers to focus on implementing features without distraction.
• Being able to iterate over ideas quickly without scrapping work from previous iterations.

With these two factors firmly taken care of, developer productivity increases and the finish line becomes nearer. GraphQL can help to solve both of these issues as they are not mutually exclusive. If a developer needs to go outside of themselves to resolve a dependency, it naturally leads to distraction and a decrease in productivity. From my experience as a developer, almost all meetings held once a project was kicked off were to resolve a dependency, many revolving specifically around API dependencies and access to data.

Since GraphQL can unify all data throughout an organization, it means that developers can access data without having to learn where to find an API they can use to get the data they need. In REST and SOAP terms, this may mean reaching out to various teams to see what APIs they have available, which they can use, and possibly getting “onboarded” to use the needed API. This is a major disruption that can suck a serious amount of time out of a developer’s week. With GraphQL they can simply look at the GraphQL schema (the document outlining what data is available) and get to the data they need, no outside assistance necessary. This is a massive achievement for developers and their organizations. It means more developers as well as other people within the organization’s tech community can enjoy greater productivity on the tasks that matter instead of admin tasks to get developers the data they need.

This very simply solves our concerns with limiting the work needed to resolve API dependencies and empowers developers to simply put their efforts into creating great code, more easily. This, in turn, eventually leads to greater overall productivity within the technical community and keeps stakeholders happy with reduced and more accurate timelines for product delivery. This is the hidden power within GraphQL. It is not only making developer’s lives more productive but also leading to a new approach to developing software at all levels.

The new wave

There is a great mix of short-term and long-term benefits associated with GraphQL. For developers, this means higher productivity and code quality. This is a quick win that has many rippling effects that will be seen for a long time to come. One of those wins for the business includes decreasing time-to-market, possibly even allowing an organization to become a first-mover with certain innovations more easily and with less cost to do so. It is a long-term play with some hurdles to overcome but the benefits to developers and enterprises are too great to dismiss.

The rapid adoption of GraphQL is no mistake. The benefits run much deeper than just “a new way to do APIs”. With it comes a major shift in how developers create applications and access the data they need. GraphQL is quickly becoming the differentiating factor between organizations that want to exist and those that want to thrive. Major tech giants around the globe are adopting this technology, even in its infancy, because they see the potential and sweeping changes to develop better products and technical organizations using it. An unprecedented amount of tools have been created to allow for easy adoption and minimal learning curve by building from the ground up or adding a GraphQL layer to existing infrastructure. The world of APIs is being forever changed. Some would even argue that GraphQL is bringing a new era to tech. A faster and smarter way to build is upon us.

Looking for a way to jump into GraphQL easily? Dgraph is a graph database that allows for data access through GraphQL. The best part is that it’s all built into the platform and easy to use. Developers can be up and running in minutes, integrating GraphQL into the simplest or the most complex applications in your portfolio. We built Dgraph to be simple for developers to use while supporting even the most complex use cases. Easy to use with the option of fearless scalability for projects of any size. To start experiencing the power of Dgraph for yourself, get started today with Dgraph Cloud.

Here are some resources that’ll be helpful for teams looking forward to adopting GraphQL:

• Dgraph Learn: Free GraphQL tutorials
• Tour of Dgraph: An interactive tutorial
• Dgraph GraphQL Docs
• Learn - graphql.org
• GraphQL specification