Building Microservices using API Gateway

Usha Devasi
4 min readApr 12, 2020

--

In the previous articles, we saw how Service Discovery works and how to configure the service registry using Eureka & Spring cloud. Now, let’s see the “API Gateway” in this article.

What to expect from this article:

  • What is API Gateway?
  • Why API Gateway is needed?
  • How to configure API Gateway using Spring Cloud & Eureka?
  • What’s the Concern and how to overcome it?

What is API Gateway?

API Gateway provides an extra layer, a single entry point lying between a group of microservices and the frontend layer/clients. The API gateway handles requests in one of two ways:

  • Some requests are simply proxied/routed to the appropriate service.
  • It handles other requests by fanning out to multiple services.

Why API Gateway is needed?

Direct Pattern: It is the pattern without API Gateway where the client is capable of making direct communication contact with microservices as shown in the diagram:

Direct pattern

This pattern is easy to configure but it has a lot of problems such as:

  • Performance Issue as it may happen that the same page of your app is getting called by many services and many a time.
  • Security issues as all the endpoints of microservices are openly exposed.
  • Scalability issues as while making any kind of change in a microservice, the change may impact service and this may also lead to difficulty in maintaining these services.
  • Complexity: The above diagram seems easy but think of yourself as a client. Will you be able to remember all the service endpoint😳? The answer is simply “No”, and that’s the big problem.

In order to solve the above problems, API Gateway came into picture fulfilling all the above points as it addresses all the concerns we just mentioned, by hiding the endpoint of microservices from the public, abstracting references to microservices from the client and reducing latency by aggregating multiple calls. So, let’s call it as API Gateway Pattern. We can put authorization in this layer too.

API Gateway Pattern:

API Gateway between client and no. of Microservices

Question: Where will my API Gateway Component gonna lay, if we are using the Service registry 🤔?

Answer: It will be placed between the client and the Service Registry as shown in the below Diagram.

Configure API Gateway using Eureka Client & Spring Cloud

Remember here that API Gateway also registers itself in Service Registry(I am considering and showing an example using Eureka). So you will be able to see all the services registered in Eureka Server and also after the successful configuration of API Gateway you will be able to access other services from the same API Gateway Url.

Pre-requisite: To configure Eureka Server and other services please refer to the link provided here as I am gonna call that service via API Gateway.

Steps:

  1. Add org.springframework.cloud:spring-cloud-starter-gateway (for API Gateway) and org.springframework.boot:spring-cloud-starter-eureka-client on your classpath.

e.g. In Pom.xml :

pom.xml

2. Add @EnableEurekaClient in Application.java OR @EnableDiscoveryClient can also be used. @EnableDiscoveryClient will work for any other Service registry.

Application.java (GateApp.java)

3. Configure application.yml, the highlighted part is the most important part while configuring API Gateway as you can see that “predicates:” shows how the URL looks like/contains.

In the below example it means that if the path contains /api/orders/ then call service named “dummy-service” however if the path contains /api/status/ then call “kitchen-service”. Similarly, we can configure as many services as we want.

Now, this is how my Service Registry looks like: Pay attention to the service names and the ports on which they are running as in the next step I am gonna run these services from their own service URL as well as from API Gateway port.

  • Dummy-service: POST : Using Dummy service URL
using localhost:8082/api/orders
  • Dummy-service: POST : Using API Gateway URL
using localhost:8080/api/orders

Concern:

What if this API Gateway got down because of some heavy traffic coming towards it as lots of Clients are using it?

Solution: Create no. of instances of API Gateway in order to achieve high scalability. So, that even if somehow one instance is not working it can be maintained by others.

Now, the question might be raised in your mind that if we create no. of API Gateway instance than how it’s gonna be handled and by Whom?

Now it comes to the Load Balancing concept (LB), we gonna discuss this in some other article.

--

--

Usha Devasi
Usha Devasi

Written by Usha Devasi

Tech Lead/ Engineering Manager, Mentor, Coach, Certified Professional Scrum Master and SomeOne who is Passionate about Learning and exploring.

No responses yet