API Gateway with Ocelot
This article is part of my Microservices and Cloud-Native Applications series. You can find the other parts of the series below.
- Saga Orchestration using MassTransit in .NET
- API Gateway with Ocelot
- Authorization and Authentications with IdentityServer
- Eventual Consistency with Integration Events using RabbitMq
- Distributed Logging with ElasticSearch, Kibana, and SeriLog
- Resiliency and Fault Tolerance with Polly
- Health Check with WatchDogs in a Microservices Architecture
- Distributed Tracing with Jaeger and OpenTelemetry in a Microservices Architecture
- Metrics to Monitor Microservices with OpenTelemetry and Prometheus
If you want to take a look at the GitHub code, you can access it here: https://github.com/ebubekirdinc/SuuCat
API Gateways play a crucial part in the microservices architecture by serving as a single point of entry for all external requests to the microservices ecosystem. Several services collaborate to supply a particular business functionality in a microservices architecture.
Since each service has its own API, it may be challenging for users to engage with the ecosystem because they may need to deal with several endpoints and protocols.
API Gateways can be useful in this situation. For all external requests, they provide as a single entry point that may be used to direct traffic to the proper microservice. By offering a single API that hides the underlying complexity of the microservices architecture, API gateways assist in reducing the complexity of client interactions.
Moreover, API Gateways offer other features like authentication, rate limiting, caching, and load balancing. These features contribute to the microservices ecosystem’s increased performance, scalability, and security.
In a Microservices Architecture, API Gateways also help in enforcing the concepts of loose coupling and encapsulation. The underlying workings of the microservices ecosystem are abstracted away by API Gateways, which
enables the services to develop independently without affecting the clients.
In SuuCat, API Gateway has been implemented using Ocelot. Ocelot is an open-source API Gateway that is designed specifically for Microservices Architecture. It is based on the ASP.NET Core framework and can be used with any backend services that are written in any language.
Ocelot can be installed using the following Docker files. More information about the installation is here: https://github.com/ebubekirdinc/SuuCat/wiki/GettingStarted
docker-compose.yml
docker-compose.override.yml
The following code is a section of the ocelot.development.json file.
This configuration specifies a route that forwards requests with certain HTTP methods and path templates to a downstream service over HTTP, while enforcing authentication using a specific authentication provider and allowed scopes.
The downstream route template to which the request will be forwarded after going via the API Gateway is specified by the term DownstreamPathTemplate. This means that any path that matches the route will be forwarded to the downstream service that has the same path because it is set to “/{everything}” in this case.
DownstreamScheme and UpstreamScheme specifies the protocol used to communicate with the downstream or upstream service.
In this case, it is set to “http” on both.
DownstreamHostAndPorts identifies the host and port that will receive the request once it has been forwarded downstream. In this case, the request will be sent to a service running on port 80 called “notification.api.”
The API Gateway will listen for requests on the upstream path template that is specified by the term “UpstreamPathTemplate”. It is set to “/services/NotificationService/everything” in this case.
Authentication
The term “AuthenticationOptions” describes the possibilities for this route’s authentication. This example only permits requests with the “notification_scope” scope and is configured to utilize the “TestKey” authentication provider.
If there is no notification_scope in the JWT token, the request will be rejected with a 403 Forbidden. More on scopes can be found in the IdentityServer4 documentation of this article series.
insert link here
Rate Limiting
In the following code, the API Gateway is configured for rate limiting.
This configuration sets up rate limiting for API requests, allowing only one request per 3-second period. After 1 second, the rate limit counter will be reset. If the limit is exceeded, the request will be rejected with a HttpCode: 429 Too Many Requests.
Caching
In the following code, the API Gateway is configured for caching.
FileCacheOptions specifies the options for file caching in Ocelot.
TtlSeconds is the time to live (TTL) for cached responses, in seconds. In this example, it is set to 60, which means that cached responses will be valid for 60 seconds, the cached response will be returned instead of
forwarding the request to the downstream service. If you put a debug point in the API method, you can see that no more requests are received after the first request within 60 seconds.
More info can be found in the Ocelot docs, and SuuCat GitHub.
