Application development has a long history of rapid evolution and transformation, perhaps faster than any other industry. The tools we use to create and host our applications are constantly changing.

The rapid development in programming tools offers ample opportunities to create software for companies of different sizes, sectors and budgets. However, the added flexibility and diversity of tools, as well as the constantly changing landscape, also bring their own challenges.

Developers need to be able to build their apps to adapt to the scale and changes their organization, customers and infrastructure undergo. Fortunately, with the shift to chart-based programming, companies will be much better equipped to maintain flexibility as they continue to 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 you can choose a container model, where your application is packaged in a docker file. You can choose from different models of data hosting and storage, including data warehouses and data lakes. And you can make these and many other choices per part of your application.

The advantage of this powerful variety of compute and storage platforms is that you can customize your application to meet the needs of your customers and your organization. The downside, however, is the added complexity associated with communicating with the many different service APIs that support your application.

GraphQL helps developers interact with APIs through flexible and structured data queries.

“Many applications need to communicate with dozens, even hundreds of services at runtime. In some cases, each application update (mobile, web, etc.) requires hundreds of API calls to various services,” said Peggy Rayzis, Sr. Director of Developer Experience Apollo Graph, Inc. “This requires a huge and complicated effort from developers, who have to make sure that all these different services are compatible and can work together.”

The added complexity also makes it difficult to iterate, add or modify features or change the underlying infrastructure. In any case, redundant implementations and inconsistencies between services force developers to make intensive changes to their code to connect all the old and new services.

Graph-based programming offers the solution

One of the trends helping developers address the complexity of the application ecosystem is graph-based programming. Graph-based programming allows developers to add a data schema layer between their application and the API services running behind the scenes. This layer of abstraction decouples these parts and allows them to evolve without causing major disturbances in each other.

“Basically, the idea is that you add an intermediary layer that allows your application to interact with your data entities by querying a graph,” says Rayzis. “The graphics layer is unified and flexible no matter what kind of infrastructure is operating behind the scenes, whether it’s an on-prem server, a cloud VM, a REST API, a data warehouse, or a serverless feature like AWS Lambda. ”

Graph-based programming was popularized by GraphQL, a data query language introduced by Facebook in 2015. GraphQL helps developers interact 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 see that 30% of Fortune 500 companies build their apps based on supergraph.

Businesses and applications of all sizes can benefit from chart-based programming. Rayzis says:

Regardless of size and structure, any application can benefit from chart-based development. As your app grows or your data infrastructure changes, your graph remains consistent and tied to your app’s logic.

For example, Walmart used GraphQL to create a federated schema of different entities used for their various applications and services offered across the web and mobile. With GraphQL, they were able to remove much of the code that is replicated in their APIs, unify their applications, and become much more flexible in rolling out features and improving the user experience.

The next generation of chart-based tools

“What we found during our more than six years of working with developers who were deploying GraphQL at scale is that its flexibility is its greatest strength, but it can also lead to some negative consequences if not implemented in a principled way.” says Rayzis.

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 is 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 layer of composition for the entire organization. The supergraph architecture is built on Apollo’s open technology, Apollo Federation. Apollo also offers GraphOS, a cloud-based platform of tools with an edge runtime and schema delivery pipeline for the supergraph. According to Rayzis:

With the supergraph, you can split the graph chart across different teams and different services, but then merge it into a single interface for the customer. It’s about solving real customer problems. It is 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 develop over time.

One of the companies that has benefited from the supergraph is Booking.com, one of the world’s largest online travel agencies. Booking.com has been around since 1996 and therefore runs a lot of legacy code and infrastructure. This makes it very challenging to change the software architecture, especially since the company employs thousands of engineers and must ensure that they can work together securely.

Thanks to the flexibility and versatility of the supergraph, Booking.com has been able to make a phased transition to GraphQL without breaking any of their services. As they gradually rolled out the supergraph across the organization, engineers and managers realized its benefits and helped accelerate the transition. The full adoption of the supergraph allows Booking.com to ship 40% faster, sometimes doubling the speed at which they release features. At the same time, they managed to significantly reduce errors and breaking changes.

“We see that 30% of Fortune 500 companies build their apps on supergraph. And I think that number will only increase in the coming years,” says Rayzis.

It will drastically lower the threshold for app development and allow more developers to create apps. It will continue to reduce the time it takes to create those apps. And so by making it more accessible and reducing that time, you’re going to see even more innovation.