The exhaustive guide to choosing between gRPC, GraphQL, and REST

With the current wave of legacy application modernization, every architect has to face this question. Which of the following to choose from — gRPC, GraphQL, or REST. The conundrum lies in choosing the right API technology for your application and needs. The correct approach will future-proof the technology roadmap for years to come and enable great developer experience, API monetization, and democratization.

API is ubiquitous and used for data exchange. The real challenge lies in cementing the correct API-led strategy. Let’s go over the basic problems we are trying to solve and the general expectations.

1. Bridge gap in data between systems(Problem) — API has to be fast, reliable, robust, and serve its clients(Expectation)
2. The whole purpose of API is to be consumed by other systems. The API needs to be exposed to the internal and external developer community(Problem) — API should be understood by a vast gamut of developers and designers to be implemented in an array of projects(Expectation)
3. How to make money off the API(Problem) — The API economy is real and when correctly implemented can result in good business(Expectation)
4. What is the use case for the API(Problem) — API can range from IoT devices sending data, backend endpoints consumed by a React App, or communication among microservices. The use-case should be dictating the correct strategy and not the other way around(Expectation)

With the goals in front of us clearly stated, different situations and problem statements will command different solutions. There is no one size fits all kind of solution here. Is there an API utopia?

REST

Wikipedia says — “The term representational state transfer was introduced and defined in 2000 by Roy Fielding in his doctoral dissertation. The term is intended to evoke an image of how a well-designed Web application behaves: it is a network of Web resources (a virtual state machine) where the user advances through the application by selecting links, resulting in the next resource’s representation (the next application state) being transferred to the client and rendered for the user.”

Simply put :

1. REST uses HTTP verbs like GET, POST, PUT, DELETE AND PATCH to interact with the resource.
2. URLs are used to address the resources. It achieves this in a stateless, cacheable manner.
3. Rest is extremely opinionated and there can be multiple levels of API maturity.
4. There can be a right and wrong way to implement Rest. I have been on both sides of the fence.

GraphQL

“GraphQL is a query language for APIs and a runtime for fulfilling those queries with your existing data. GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools” from GraphQL.org.

It allows you to describe the schema and query exactly what is needed through the API. The convoluted world of knowing which endpoint to use for which resource is all resolved through one common API endpoint.

For example, below we will invoke a local API and pass id: “book-2” in the request and want the fields in response.

# Write your query or mutation here
{
  bookById(id: "book-2") {
    id
    name
    pageCount,
    author{
      firstName,
      lastName
    }
  }
}

The response on the right side is controlled by the requester.

This is highly useful if the consumer is a front-end App that can make highly complex aggregation calls through a single endpoint. A faster and simpler way to get data in one go. What is of interest here is that GraphQL is a great option for front-end apps and may not be a good option for backend service to service communication. There is also an emerging trend of using GraphQL with TypeScript. In pure backend data processing, developers tend to align more to simpler Rest APIs.

gRPC

gRPC is from Google and has a unique take on HTTP/2. Google decided to create a well-balanced project which can take advantage of HTTP2 and reap all the benefits. Developers who want to flex how efficient and fast their APIs are should be using gRPC. gRPC is the need-for-speed alternative world of Rest and GraphQL.

Owing to proto buffers, data is transmitted in binary. This is blazing fast compared to Rest and GraphQL where data is moved around in text format. This has both pros and cons. Due to the human readability of XML, and JSON, it's easier to view data if required but with binary data that goes out of the window. Of course, developers have devised other ways to gleam at the data but it's not out of the box.

Bottomline

There is no clear winner here and it all comes down to the group of developers, designers, and architects making the decision here. There is no one size fits all solution here when it comes to API and rather experience, needs, skill, and budget at play. Let's not jump to the next shiny thing just because it's cool. As always, the problem at hand should merit the device.