In the microservices architecture, lots of API services work together for the distributed application. There could be more than 100 API services and UI components talking to each other for a business goal. So, these UI components must know about all microservices endpoints with a port to call these API services if you are not using API Gateway.

An API Gateway mechanism is required when you want to implement the common aspects for your distributed application, such as CORS, authentication, security, and monitoring, in terms of this design. If you are not using API Gateway, then you have to implement these aspects into all API services, so the same code will be repeated over all microservices. To avoid this problem, we have to use a common service or entry point where all common aspect code is written and the client will call that common service.

Let's see the following diagram of a distributed application without an API Gateway service:

As you can see, each UI component must be aware of each service endpoint using the Eureka Server. The UI component of the Customer-Service must have information about the endpoint of the Customer microservice that is registered with the Eureka Server. Similarly, the UI component of the account must be aware of the endpoints of the Account microservice. It is sometimes very complex to maintain and remember the endpoints of each API service, and our microservices implementations don't want to expose these endpoints to the outside world for security reasons. We want to keep these API services private. In this case, instead of letting UI components know about all the actual endpoints of the API services, we can provide API Gateway, which will delegate all API calls to the individual microservices working behind the scenes.

API Gateway is a unified proxy interface delegating the calls to several microservices-based on the URL pattern. In this chapter, we will implement this API Gateway proxy using Spring Cloud's Zuul Proxy. This API Gateway interface allows us to expose a set of public services to the outside client without any security breaches. Let's see the following diagram with an API Gateway interface to call API services:

As you can see in the preceding diagram, the UI component calls the API services through API Gateway. Now, each UI component doesn't need to know the actual endpoint of the individual microservice. We have exposed a single service, that is, the API Gateway service with a host and port for all UI components. This API Gateway service is also known as Edge Service because this service sits on top of all the other microservices in a distributed application. All clients will call this Edge Service as a proxy for all internal microservices.

Let's see the pros and cons of using the API Gateway proxy service in the next section. There are many reasons to use the API Gateway service on microservices-based applications, we have discussed some of them. There are listed pros and cons of the API Gateway pattern in the next sections.