API Gateway(Microservice)

A possible approach is to use a direct client-to-microservice communication architecture. In this approach, a client app can make requests directly to some of the microservices.

In this approach, each microservice has a public endpoint, sometimes with a different TCP port for each microservice.

A direct client-to-microservice communication architecture could be good enough for a small microservice-based application, especially if the client app is a server-side web application like an ASP.NET MVC app. However, when you build large and complex microservice-based applications (for example, when handling dozens of microservice types), and especially when the client apps are remote mobile apps or SPA web applications, that approach faces a few issues.

Consider the following questions when developing a large application based on microservices:

1. How can client apps minimize the number of requests to the back end and reduce chatty communication to multiple microservices?. So if you have API gateway then you’re your microservices connected to one API gateway for this.
2. How can you handle cross-cutting concerns such as authorization, data transformations, and dynamic request dispatching?. If you have API gateway then you have to use one API request and one authentication and data transformation for that one gateway API only.
3. How can client apps communicate with services that use non-Internet-friendly protocols?. Your microservice are hosted as tcp and then your API gateway internally calling your microservices and only your API gateway is exposed to the internet.
5. How can you shape a facade especially made for mobile apps?. You can expose your façade interface on tcp which called as microservices and then API gateway use those tcp APIs and expose to intermate.

Apps connect to a single endpoint, the API Gateway, that's configured to forward requests to individual microservices. In this example, the API Gateway would be implemented as a custom ASP.NET Core WebHost service running as a container.

It's important to highlight that in that diagram, you would be using a single custom API Gateway service facing multiple and different client apps. That fact can be an important risk because your API Gateway service will be growing and evolving based on many different requirements from the client apps. Eventually, it will be bloated because of those different needs and effectively it could be pretty similar to a monolithic application or monolithic service. That's why it's very much recommended to split the API Gateway in multiple services or multiple smaller API Gateways, one per client app form-factor type, for instance.

Therefore, the API Gateways should be segregated based on business boundaries and the client apps and not act as a single aggregator for all the internal microservices.

Main features in the API Gateway pattern

1. Reverse proxy or gateway routing. The API Gateway offers a reverse proxy to redirect or route requests to the endpoints of the internal microservices. The gateway provides a single endpoint or URL for the client apps and then internally maps the requests to a group of internal microservices. And it also help when you want to have change in your microservice or want to build new logic/version/url/hstoin of microservice then no need to ask/notify client as you will be changing at your side and API gateway is only being use by client which should not impact.
2. Requests aggregation. As part of the gateway pattern you can aggregate multiple client requests (usually HTTP requests) targeting multiple internal microservices into a single client request. This pattern is especially convenient when a client page/screen needs information from several microservices. With this approach, the client app sends a single request to the API Gateway that dispatches several requests to the internal microservices and then aggregates the results and sends everything back to the client app. The main benefit and goal of this design pattern is to reduce chattiness between the client apps and the backend API.
3. Cross-cutting concerns or gateway offloading. Depending on the features offered by each API Gateway product, you can offload functionality from individual microservices to the gateway, such as the following functionality:
• Authentication and authorization
• Service discovery integration
• Response caching
• Retry policies, circuit breaker, and QoS
• Rate limiting and throttling
• Load balancing
• Logging, tracing, correlation
• Headers, query strings, and claims transformation
• IP whitelisting

Using products with API Gateway features

There can be many more cross-cutting concerns offered by the API Gateways products depending on each implementation. We'll explore here:

• Azure API Management

Azure API Management not only solves your API Gateway needs but provides features like gathering insights from your APIs. It also solves both your API Gateway and Management needs like logging, security, metering, etc.

• Ocelot

Ocelot is a lightweight API Gateway, recommended for simpler approaches. Ocelot is an Open Source .NET Core based API Gateway especially made for microservices architecture that need unified points of entry into their system. The main reason to choose Ocelot is because Ocelot is a .NET Core lightweight API Gateway that you can deploy into the same application deployment environment where you're deploying your microservices/containers, such as a Docker Host, Kubernetes, etc. And since it's based on .NET Core, it's cross-platform allowing you to deploy on Linux or Windows.