Choosing the Right Applications for gRPC

Choosing the Right Applications for gRPC

Table of Contents:

1. Introduction
2. Comparing gRPC with REST and GraphQL
3. When does gRPC make Sense? a. Request-response for UI and view composition b. Interacting with infrastructure c. Originating from a message
4. Avoiding gRPC in service-to-service communication a. Distributed turd pile b. Lack of resiliency in long-running workflows
5. Conclusion

Comparing gRPC with REST and GraphQL

gRPC has become a popular topic of discussion in the world of service communication. Many blogs and videos claim that gRPC should be the de facto standard for communication between services, but they often fail to provide a compelling reason for this assertion. In this article, we will explore various situations and contexts where gRPC can be a viable option, as well as those where it may not be the best choice. We will also discuss the advantages and disadvantages of gRPC compared to REST and GraphQL.

When does gRPC make sense?

a. Request-response for UI and view composition

One Scenario where gRPC shines is when there is a need for request-response communication, particularly in UI and view composition. For instance, if a client needs to retrieve data from multiple services to construct a view model or UI, gRPC can be a powerful tool. By using gRPC, the client can make requests to an API gateway or backend for front-end, which then communicates with various services using gRPC. This allows for efficient composition of data and rapid construction of the desired UI.

b. Interacting with infrastructure

Another suitable use case for gRPC is when interacting with infrastructure components like databases. While databases aren't strictly considered services in terms of business capabilities, they are an essential part of most workflows. For example, when utilizing event sourcing or working with a stream database like Event Store DB, using gRPC clients can provide a natural and efficient way to communicate with the underlying database infrastructure.

c. Originating from a message

The origin of a request also plays a crucial role in determining whether gRPC is a suitable choice. If the request originates from a message pulled from a queue or broker, rather than directly from an end user, gRPC can be a valuable option. This distinction allows for more resiliency and fault tolerance in dealing with failures. With messages, You have the flexibility to implement automatic retries, exponential backoff, and even dead letter queues if necessary.

Avoiding gRPC in service-to-service communication

a. Distributed turd pile

One significant drawback of relying on gRPC for service-to-service communication is the increased coupling and complexity it introduces. When services directly communicate using gRPC, the system can Resemble what we call a "distributed turd pile." This term refers to a situation where there is no fundamental difference between a monolithic architecture and a distributed one. The network introduces additional points of failure without reducing coupling. Consequently, building resilient systems can become extremely challenging.

b. Lack of resiliency in long-running workflows

Consider a scenario involving long-running workflows and business processes that span multiple services. In such situations, direct service-to-service communication using gRPC is not recommended. Using messaging and decoupling the services temporarily allows for better fault tolerance and ensures that all services do not need to be online simultaneously for the workflow to be executed. By adopting orchestration or event choreography through messaging, services can communicate through messages, events, and replies, maintaining loose coupling and ensuring resiliency.

Conclusion

In conclusion, gRPC offers several advantages in specific scenarios, such as request-response communication for UI and view composition or interacting with infrastructure like databases. However, it is crucial to consider the Context and originating point of a request. When it comes to service-to-service communication involved in workflows and long-running business processes, gRPC may not be the best choice. Instead, messaging and decoupling strategies provide more flexibility and fault tolerance. By understanding these different scenarios, developers can make informed decisions about when to leverage gRPC and when to explore alternative communication approaches.