REST, gRPC and GraphQL - Part 2 - Pros and Cons

I am assuming that you have read Part 1 of my article or the JetBrains .NET Annotated Newsletter April 2023 edition to understand the basics. So let us continue to look at the pros and cons of each API Paradigm.

gRPC 

Pros 

Lightweight Messages - The requests and responses are in binary format where each field is serialized against a unique number for the field. Further, fields that are not assigned any value are not serialized for transmission. This keeps the messages lightweight. This also leads to reduced network usage.

High performance - Designed for HTTP/2 and beyond and combined with the magic of Protocol Buffers gRPC is very performant and makes a perfect candidate for such scenarios

Streaming Options - gRPC makes use of the streaming capabilities of HTTP/2 and provides 3 modes - Client Streaming, Server Streaming and Bi-directional Streaming

Support for versioning - Versioning can be achieved in gRPC, even as an afterthought, in gRPC. Protocol Buffers are smart, they are forward and backwards-compatible and with some rules followed versioning can easily be achieved. 

Tooling Support - protoc compiler understands a wide variety of languages and can generate code that makes gRPC a candidate for polyglot systems

Cons

Client-Server coupling - Being contract-based, there is always a level of coupling between client and server

Limited browser support - gRPC clients are not very well supported by browsers, so gRPC is not the best option for browser-based apps. However, you can use gRPC-web or gRPC JSON Transcoding to use gRPC in your browse-based apps.

Discoverability - gRPC is not very discoverable unless you use third party tools to share the API contract

Function overload - The key feature of gRPC can go against itself when you start having more and more rpc definitions in your proto files. This can even get more complicated when you start having versions of your service to maintain.

REST

Pros

Decoupled client and server - A complete REST-ful system, with HATEOAS in place, decouples the client and the server where each can evolve at their own pace. 

Scalable

Seamless integration with HTTP - REST APIs most commonly use HTTP as the transport. REST was put in place to standardise distributed systems, like the web, that ran on HTTP. So there is a crossover between HTTP and REST and REST makes use of the HTTP toolkit. Furthermore, this makes it easy to consume. Because any client that can issue an HTTP request can consume a REST API. This explains the popularity of REST.

Superior browser support 

Tooling - REST benefits from a wide variety of tools to test your APIs and expose your API contracts 

Cons

Chatty - REST can be chatty, as I wrote in part 1 of my article. This can be heavy on your bandwidth and in this era of being sustainable, this is not very green, considering the data wastage. The payloads can be huge. There can be overfetching, underfetching and N+1 problem on the client if REST APIs are not used in appropriate scenarios.

Not a spec - REST is more of a pointer or guide on how your systems should be. There is no spec when it comes to the implementation, unlike gRPC or GraphQL which are more of a specification.

GraphQL

Pros

Exact fetching - GraphQL benefits from exact fetching where the client decides what they want and the server gives them only what has been asked. So overfetching and underfetching don't come into the picture.

Decoupled client and server - GraphQL is client-focused and client-driven. With exact fetching in the mix, it enjoys a completely decoupled client and server where client and server can evolve at their own pace.

Autogenerating API documentation and tooling support - GraphQL, by specification, is introspective - it can query itself to gather information. This has led to a wide variety of tools like GraphiQL, Insomnia, Banana Cake Pop and even Postman that can expose the schema in a friendly format to the consuming developer. Furthermore, this has also led to IntelliSense support, and error highlighting in these tools which can be of great use to the consuming developer. This helps in exposing your API contract, the schema, and there are tools available to create beautiful documentation sites out there.

Cons

Steep learning curve - GraphQL has a steep learning curve. I found it more difficult to understand and grasp the concepts behind GraphQL than gRPC or REST

Growing Community

Performance with complex queries

Caching complexity - GraphQL queries usually work with an HTTP POST. HTTP POST operations are not cacheable. So you have to resort to persistent queries to allow for caching.