Chain of Responsibility In Microservices

To construct an application in today’s industry, microservices have become the standard solution. Various problems can be solved using them; however, even experienced professionals face issues while using this design. Instead, developers can look for common patterns in these issues and develop reusable solutions to improve the application’s speed.

A single answer to a request is generated using the’ chained microservices’ paradigm. In this scenario, Service A receives a request from the client and forwards it to Service B, then forwards it again. Asynchronous HTTP request/response messaging is presumably used by all services.

Keep in mind that the client cannot proceed until the entire request/response cycle has been finished. The chain should not be too long. If you’re using a web page waiting for the response, you’ll see a long delay due to the chain of command’s synchronous nature. The term “singleton chain” refers to a chain that contains a single microservice and may be able to grow in the future.

The Chain of Responsibility pattern is part of the Gang of Four behavior pattern family and deals with how objects in an application communicate with one another and their responsibilities. Every one of these patterns is based on the idea of “object composition rather than inheritance.” Developers widely adopt this concept because of its advantages. 

Rather than building on top of an existing object, this approach proposes creating a new object that refers to an already existing object. We’ll utilize an instance variable that points to the class object to do this. The referred object can be utilized once it has been initialized, whether through the function Object in native code or a method.

Let’s Gain Some Insight Into the Chain of Responsibility Pattern

Using the Chain of Responsibility pattern is a straightforward process. A request is always started by a client and handled by an application object. According to the Chain of Responsibility design, decouple the client from the object that handles the request. Handler objects, also known as responding objects, handle requests of a given type. Handler objects are chained together if they can’t handle a given request. One or more generic handler objects will handle the request at the end of the chain. 

Customer Service’s technical help desk can be used as an analogy for the Chain of Responsibility design when you call in with a technical question or issue (think of yourself as a request object). As a first step in the chain of events, a technical help desk executive addresses it. A billing help desk executive takes over if they can’t resolve it — perhaps due to a billing-related issue (the second object). There is a third object, the general help desk (the third object) if neither the billing help desk nor the general help desk can address your issue.

When and Where the Chain of Responsibility Pattern Can Be Applied

• When you need to separate the sender and receiver of a request.
• Candidates for handling a request are determined during runtime.
• To avoid specific handlers in your code, you can use this technique.
• When you want to send a request to a specific object but don’t know which one.
• This approach is recommended when numerous objects can handle a request, and the handler does not have to be a single object. In addition, the handler is chosen on the fly.

Handler 

For all concrete handlers, the Handler declares an interface that is the same. Only one method is usually provided for handling requests; however, this method may also be used to determine the next handler in the chain.

Base Handler

An optional class called Base Handler is used to store boilerplate code for all handler classes. The following handler is often stored in a field defined by this class. When a client passes a handler to the previous handler’s function Object or setter, the chain can be built. Alternatively, the class can implement the usual handling behavior: it can simply send execution to the next handler after determining whether or not the current handler exists.

Concrete Handler

Three concrete handlers include the code for processing requests. Receivers of requests must select whether or not to process them before passing them along to the next handler in their respective line of command. Handlers are normally self-contained and immutable, accepting all necessary data once via the function Object.

Client

Depending on the program's logic, the client may create chains only once or dynamically. This doesn’t necessarily mean the first handler in the chain receives a request.

Advantages of the Chain of Responsibility Pattern

• To lessen the degree of connection. The transmitter and receiver must be separated to do this.
• Uncomplicated thing. Nothing about the chain structure is essential knowledge for the item.
• The flexibility of objects assigned tasks should be improved. One can dynamically add and remove responsibility by rearranging the chain members or rearranging their order.
• Increase the processing of requests to a new level of comfort.

Disadvantages of Chain of Responsibility Pattern

• The receipt of the request is not a guarantee but rather a requirement.
• As a result, the system’s performance will be hampered, and the difficulty of debugging the code.
• Due to debug, it may be difficult to see the characteristics of the operation.

Conclusion

Chained Patterns combine numerous linked outputs to form a single result. The request from the client is initially received by Service A if there are three services in a chain. The next step is to communicate with Service B and gather data. Finally, the second service communicates with the third to produce the consolidated result. 

All of these services use synchronous HTTP requests and responses. In addition, the client doesn’t receive any output until the request has passed through all of the services and received the appropriate replies.