Application development has a long history of quick evolution and transformation, perhaps faster than any other industry. The tools we use to create and host our applications are constantly changing.
The fast developments in programming tools provide plenty of opportunities to create software for companies of different sizes, industries, and budgets. However, the added flexibility and diversity of tools — as well as the constantly changing landscape — also introduce their own set of challenges.
Developers must be able to create their apps in ways that can adapt to the scale and changes that their organization, customers, and infrastructure undergo. Fortunately, with the shift toward graph-based programming, companies will be much better equipped to maintain their agility as they continuously grow and adapt to the needs of their customers.
The challenges of modern application development
One of the blessings — and curses — of modern application development is the many options you have.
You can choose between running your application on your own servers, in the cloud, or in a hybrid model. You can use a serverless model, where a cloud provider manages your server in the background and you focus on functionality, or choose a containerized model, where your application is packaged into a docker file. You can choose between different models of data hosting and storage, including data warehouses and data lakes. And you can make these and many other choices for each component of your application.
The benefit of this powerful variety of computing and storage platforms is that you can adjust your application according to the needs of your customers and your organization. However, the downside is the added complexity that comes with communicating with the many different service APIs that support your application.
GraphQL helps developers communicate with APIs through flexible and structured data queries.
“Many applications must communicate with dozens, even hundreds of services during runtime. In some cases, every application update (mobile, web, etc.) requires hundreds of API calls to different services,” says Peggy Rayzis, Sr. Director of Developer Experience at Apollo Graph, Inc. “This requires a huge and complicated effort by developers, who must ensure all these different services are compatible and can interoperate.”
The added complexity also makes it difficult to iterate, add or modify features, or change the underlying infrastructure. In each case, redundant implementations and inconsistencies between services force developers to go through intensive changes in their code to connect all the old and new services.
Graph-based programming to the rescue
One of the trends helping developers tackle the complexity of the application ecosystem is graph-based programming. Graph-based programming enables developers to add a data schema layer between their application and the API services that run behind the scenes. This layer of abstraction decouples these parts and enables them to evolve without causing major disruptions in each other.
“Basically, the idea is that you add an intermediate layer that enables your application to interact with your data entities by querying a graph,” Rayzis says. “The graph layer is uniform and flexible, regardless of what kind of infrastructure is working behind the scenes, whether it’s an on-prem server, a cloud VM, a REST API, a data warehouse, or a serverless function such as AWS Lambda.”
Graph-based programming was popularized by GraphQL, a data-query language introduced by Facebook in 2015. GraphQL helps developers communicate with APIs through flexible and structured data queries. This makes it easier for the developer to focus on the data schema and logic of the application and also maintain the stability of the application as the APIs evolve and change.
We’re seeing 30% of fortune 500 companies building their apps on the supergraph.
Companies and applications of different sizes can benefit from graph-based programming. Rayzis says:
Regardless of size and structure, every application can benefit from graph-based development. As your app grows or your data infrastructure changes, your graph remains consistent and remains tied to the logic of your app.
For example, Walmart used GraphQL to create a federated schema of different entities used across their different applications and services offered on web and mobile. With GraphQL, they could remove a lot of the code being replicated across their APIs, unify their applications, and become much more agile in rolling out features and improving the user experience.
The next generation of graph-based tools
“What we found over our six-plus years working with developers implementing GraphQL at scale is that its flexibility is its greatest strength, but it can also lead to some negative consequences if it isn’t implemented in a principled way,” Rayzis says.
These limitations led to the idea of the supergraph, Apollo’s special implementation of GraphQL. The supergraph goes beyond the basic benefits of GraphQL, which are to replace data-fetching and backend for frontend (BFF) code with schema and queries. It brings together a company’s data, microservices, and digital capabilities, creating a unified composition layer for the whole organization. The supergraph architecture is built on Apollo’s open technology, Apollo Federation. Apollo also provides GraphOS, a cloud-based platform of tools with an edge runtime and schema delivery pipeline for the supergraph. According to Rayzis:
The supergraph allows you to distribute the graph schema across different teams and different services, but then unify it together into one interface for the client. It’s about solving real customer problems. It’s based on our years of experience, helping customers implement GraphQL. And really, the main principles are that it’s one unified layer, built-in modules that you can evolve over time.
One of the companies that have benefited from the supergraph is Booking.com, one of the world’s largest online travel agencies. Booking.com has been around since 1996 and is thus running a lot of legacy code and infrastructure. This makes it very challenging to change the software architecture, especially as the company employs thousands of engineers and needs to make sure they can collaborate safely.
Thanks to the flexibility and versatility of the supergraph, Booking.com was able to make a phased transition to GraphQL without breaking any of their services. As they gradually rolled out the supergraph across the organization, the engineers and managers realized its benefits and helped accelerate the transition. The full adoption of the supergraph has enabled Booking.com to ship 40% faster, sometimes doubling the speed at which they’re releasing features. At the same time, they’ve managed to considerably reduce mistakes and breaking changes.
“We’re seeing 30% of fortune 500 companies building their apps on the supergraph. And I think that number is only going to increase in the years to come,” Rayzis says.
It’s going to dramatically lower the barrier for app development and make it so that more developers can create apps. It’s going to continue to reduce the time needed to create those apps. And so by making it more approachable, and reducing that time, you’re going to see even more innovation.
