Martin Buhr
Martin Buhr is the founder and CEO of Tyk Technologies, a popular open source API Gateway and Management Platform. Martin has taken Tyk from an open sourced side-project to a successful and still-independent commercial offering with employees and clients around the world. The Tyk platform now powers billions of transactions for some of the world’s largest brands including Starbucks, Capital One, AXA Insurance and the Financial Times. Overseeing Tyk from his New Zealand base, Martin is a self-proclaimed digital hippie, maker, gopher, and a passionate advocate of open source.

In the last couple of years, developers, start-ups, and enterprises alike are adopting GraphQL at a staggering rate. The passion in the GraphQL community for the technology has it spreading like wildfire.

Many companies are trying to implement GraphQL and while the technology is still relatively new, the rate of adoption across various industries is impressive. In 2012 Facebook wrote the GraphQL specification and three years later it was released to the public in 2015.

GraphQL is a query language for your API and a server-side runtime to execute queries by using a type system you define for your data. It isn’t tied to any specific database or storage engine and is instead backed by your existing code and data. GraphQL can also be seen as an alternative to other API architectural styles like REST and RPC.

Read More:   Update The End of the Beginning for Apache Cassandra

GraphQL allows for greater flexibility with data queries where multiple microservices are queried. One query can be constructed to fetch data from multiple endpoints, so you get all the information you need with a single call. This declarative data fetching is particularly helpful on mobile devices, where an abundance of network requests may consume limited battery and bandwidth resources. The intuitiveness of the query language makes it simple to express the data requirements and operations of even the most complex application.

It also allows for introspection so that developers can retrieve the schema associated with a GraphQL endpoint. This functionality will tell you the kinds of queries that are supported and can be used for the auto-generation of API documentation. Unlike RESTful APIs, which can support this functionality through blueprints and Open API Specifications, GraphQL endpoints guarantee this functionality since the schema is mandatory.

But GraphQL is very much still in the “hype cycle” of its development and as a result, many organizations are still exploring how to get it right.

Where It’s Working

In the travel sector businesses like Airbnb and Expedia have used GraphQL to gain a competitive edge.

Airbnb looked to the technology to help shift towards automation to bring speed and scale. The travel marketplace took an incremental migration approach and shifted its entire stack to utilize GraphQL and the Apollo GraphQL client with React Hooks, while moving away from Redux.

Expedia Group has moved away from its RESTful API strategy, which was causing hardships for development teams, in favor of a GraphQL approach

In 2019, Airbnb software engineer Brie Bunge said about 5.8% of all Airbnb traffic involves GraphQL, and she expected that number to reach 10% by the end of last year. Today, with the help of GraphQL, Airbnb is moving exceptionally fast and automating as much of the process as possible, improving productivity and performance along the way.

Read More:   Update Brooklyn Microgrid: A Blockchain-based Platform for Locally Traded Electricity

While for Expedia, GraphQL is transforming its goals to create seamless customer experiences across their frontend platforms. Improving customer experiences across 200 booking sites and 25 brands isn’t easy and requires the creativity and careful orchestration of thousands of developers and dozens of backend service teams.

Today, Expedia Group has moved away from its RESTful API strategy, which was causing hardships for development teams, in favor of a GraphQL approach that better lends itself to their organizational and development needs.

Finally, LinkedIn has organized its “economic graph” of relationships between users, using a unified graph to hide complex systems behind a simple GraphQL API. They are leveraging the technology to enable a consistent access experience across online, nearline, and offline environments.

Managing GraphQL with API Management

One thing that’s consistent from these case studies of adopting GraphQL is the power and flexibility it allows developers to have as they can define the data they want, as they want it. It’s an exciting value proposition, particularly given the fact that mobile devices are becoming powerful enough to perform data aggregation chores that previously could only be executed in the data center.

GraphQL is well-positioned to become a go-to technology for data access across all platforms. As shown, there is a lot of value in strategically leveraging this technology over the typical RESTful API route, especially when data needs across platforms are similar.

And for companies that deal with rapidly changing data, GraphQL can solve many of the pain points that REST APIs present. Leveraging an API management platform that has GraphQL functionality can help address some of the larger hurdles GraphQL presents by adding authorization to GraphQL services including rate limiting, quotas, and field-based access permissions.

There is one clear challenge for many organizations when it comes to GraphQL. Legacy IT infrastructure and services. To build things with GraphQL and put it in front of databases or services, you need to be using a GraphQL first approach — which many won’t already be doing.

Read More:   Update Tutorial: Use Google Config Connector to Manage a GCP Cloud SQL Database

If you have legacy services in play, it will mean overhauling these and re-writing them in a GraphQL friendly way. This can be complicated when it comes to managing how these services are interacting with APIs.

What’s needed is a solution to stitch together all the existing services that are being used, including legacy code written in REST. This would allow multiple data sources, from different backends, to be funneled together and made available in a unified GraphQL format.

We call this concept the universal data graph: a way to take all the data in your organization, without having to change it and access it all through a single interface that has all the benefits of full lifecycle API management.

In the longer term, while moving towards a data-driven enterprise architecture, GraphQL can become a major component. And the concept of a universal data graph means that a single endpoint can replace potentially thousands of microservices and reduce the complexity of networked applications in the process.

Ultimately this will free up developers who won’t need to write as much code and allow them to focus on more creative and valuable projects and activities.

Develop and evolve. Simplifying GraphQL and making it more accessible is key. And this relies on the right API management platform to help leverage the benefits and power of GraphQL, with none of the drawbacks. Allowing, frontend developers to focus on the consumption of the API services and the application business logic — while backend developers can focus on their underlying services.

Feature image via Pixabay.

InApps is a wholly owned subsidiary of Insight Partners, an investor in the following companies mentioned in this article: Apollo GraphQL.