GraphQL has a role beyond API Query Language - being the backbone of Application Integration. Are you ready to embrace it?

GraphQL has gained pre-eminence in the last couple of years as the API Query Language of choice. It has been adopted by several hundreds of prominent enterprises and products. But is GraphQL only about API Query Language? Does it have a bigger and perhaps more important role to play in building the integrated and SaaS-first enterprise? Can GraphQL solve the integration challenges faced by the products and adopting enterprises?

Proliferation of SaaS

SaaS market grew at 17.8% between 2015 – 2020, and BI market at 8.4% during the same time period; furthermore, these markets are projected to grow at 28.3% and 12.2% respectively through 2025. AI has undoubtedly stolen the march in the recent past – the AI market grew at a whooping 78.5% between 2015 to 2020 and is projected to grow at 47.8% through to 2025.

Organizations – small and large – have embraced the SaaS delivery model and are increasingly relying on SaaS applications to run their businesses. Typically, a firm of 250 employees uses at least 11 SaaS applications, and about 34% firms rely solely on small applications to run their business.

The shift towards the SaaS applications and approach of deploying multiple SaaS applications has resulted in redrawing and/or re-prioritisation of integration use-cases and approach.

API is at the Center of Integration Efforts

At a very high-level Automation and Analytics have been the key drivers for Integration Programs. Businesses either want to gain productivity (to meet SLAs, compliances et al. without significant human intervention) or Visibility into their operations.

Traditionally, businesses invested in a set of softwares that would form the backbone of their IT infrastructure to support the business operations. These limited sets of softwares would typically run on-premise and are supported by vendors which were open to perform highly customizable implementations. These systems would typically be tied together by a BPM/Workflow Management tool and Data warehouse + Reporting and BI platform to fulfil the automation and analytics needs.

Integration of these softwares would often involve databases, flat file sharing, service buses et al. This approach towards integration of softwares has gradually shifted as more and more enterprises became comfortable with the adoption of cloud and SaaS. SaaS vendors themselves have gradually shifted from Private API or Partner Only API Access to the API for All model.

If you ask a modern day engineers who have entered the software engineering world post 2010, most equate Software Integration to REST API integration.

History & Evolution of API

As we see from the above illustration, the notion of API has been around for over 3 decades and has resulted in several attempts made by tech giants and startups to simplify the process of applications talking to each other and applications sharing data to achieve the high-level goals of automation and analytics.

Focusing on the latest 3 in the above illustration, SOAP gained immense popularity in the nineties and continued till mid of the first decade of the 21st century. SOAP was schemeful; it asked developers to strictly define the contracts and used an XML-based data exchange mechanism. It tried to greatly simplify application to application communication vis-a-vis RPC and CORBA. However, due to high overheads (read payloads), botched up implementations, shift in the way user interfaces were getting built (read RIA), and the inability of legacy applications to provide the support, SOAP was soon replaced by REST as the #1 choice.

REST is so ubiquitous that for the maximum number of developers, API equals REST. While gRPC and GraphQL have grown in terms of interest from the software engineering community (see the chart below), REST remains the most adopted and de-facto choice for the most

Why GraphQL is best suited for SaaS Application Integration?

As an API Query Language, GraphQL has several advantages (and some disadvantages too) over other interface protocols/mechanisms:

1. It is schemaful and provides more control to the API clients. It enables clients to introspect (the schema), build efficient data queries, and receive web-hooks like notifications
2. It has a mature ecosystem of tools and platforms, and has a rapidly growing community (see illustration)
3. It offers better change resilience
4. It allows better handling of deprication
5. It enables development of better client side tooling and re-usable data layers

...but GraphQL - turbocharged by As we see from the above illustration, the notion of API has been around for over 3 decades and has resulted into several attempts made by tech giants and startups to simplify the process of applications talking to each other and applications sharing data to achieve the high level goals of automation and analytics ever growing ecosystem of tools and platforms - has something else to offer which should pique interest of those looking at solving application integration problem in the (current) SaaS era.

The combination of Schema-fullness, a rich set of constructs to define schema and operations, and extensibility through custom directives has enabled GraphQL based gateways, frameworks, and platforms to explore ways to stitch, federate, and meaningfully combine several data-sets or APIs or applications into a unified integrated API.

The promise of Unified API and Schema stitching opens up several interesting possibilities as vendors and businesses try to fulfill the ever-growing need to interoperate. The promise and opportunity that it presents have led vendors and developers to develop GraphQL wrappers or connectors on top of existing data sets and REST APIs. This in effect transforms GraphQL as an important piece of the integration jigsaw, notwithstanding its adoption as an API Query Language.

You can invest in building GraphQL capabilities and tools while being assured of high returns as your integration use-cases grow wider and deeper.

‍