So, I have recently been on a journey to understand the Microservices architecture and building tools that can help in deployment and management of Microservices. During this, I along with a team of some awesome developers went on in a hackathon, where we brainstormed on the idea and tried to expand it. Continuing on the idea of a Microservices registry server as explained in Part 1 of the series, we started to build an API Gateway. Just think, what use would a Service Registry have been, if there is no application consuming the data.

So, what exactly on this earth an API Gateway is?

What is an API Gateway

An API Gateway is an implementation, that acts as a single entry point to your application. Some of the tasks that are performed by an API Gateway include:

Request Routing : When a request arrives at the API Gateway, the gateway is responsible for forwarding it to the appropriate Microservice.

: When a request arrives at the API Gateway, the gateway is responsible for forwarding it to the appropriate Microservice. Composition : A single end-point on API Gateway can invoke multiple Microservices to generate the response.

: A single end-point on API Gateway can invoke multiple Microservices to generate the response. Protocol Translation: There might be a chance that the Microservices are based on different protocols, the API Gateway is responsible for translating the client requests to the optimal protocol that the Microservice can handle.

The advantage of implementing an API gateway are enormous. These may include:

Offloading the API requests from client to server

Better management of different protocols

Ease of modification

Increased robustness in case of service failure

Providing custom end-points for different devices

While designing our API Gateway solution, we kept the above points in mind and added a few more. So, what did we build?

Our Solution

So, while designing our solution, one of the primary aim was, it should efficiently use our Registry server. So, with that in mind, the first thing we implemented was, a proper way through which the gateway can communicate with the server. This was made possible by the use of server client library. The client library is what makes the cross application communication ease. For the communication, we effectively use the XML-RPC protocol.

So, what our solution is capable of:

Dynamic Request Rerouting : When the request is made to the gateway, it find the Microservices that can handle the request. Then, the gateway communicates with the server to find, where the Microservice is running and effectively re-routes the request to the appropriate Microservice.

: When the request is made to the gateway, it find the Microservices that can handle the request. Then, the gateway communicates with the server to find, where the Microservice is running and effectively re-routes the request to the appropriate Microservice. Load Balancing : The requests being routed by the API gateway are assigned to services in a round robin manner, so as to balance the load among the services.

: The requests being routed by the API gateway are assigned to services in a round robin manner, so as to balance the load among the services. Robustness: Failures can happen anytime. Keeping this in mind, we need to take care that our application never fails. The gateway, is able to provide cached answers in case the Microservice cannot be reached.

Failures can happen anytime. Keeping this in mind, we need to take care that our application never fails. The gateway, is able to provide cached answers in case the Microservice cannot be reached. Flexibility: Our solution provides flexibility. This is done by dynamically reloading the API end-point table when a new endpoint is added to the API gateway.

This was one of the solution that we hacked upon during the course of the hackathon. Well, we won too 🙂

Want to see, what we built? Head over to the repository at Github

Also published on Medium.