Building an API Gateway using Ocelot + gRPC — Part 1

Published in

.Net Programming

6 min readSep 20, 2023

Those who have already read my other articles must have noticed that I try to be a little more practical, I explain some concepts in a simpler way and then we go to a more hands-on part, but this time the topic is more complex and I thought that just going to the code example without explaining the theory could be frivolous on my part, because of that this article will be divided in two parts, this first one with a theoretical part explaining the functions and benefits of an API Gateway, and the second part that will be totally practical building an API Gateway using Ocelot and gRPC.

Introduction

The API gateway is not a new concept but it has gained traction with the popularization of microservices architecture, this is because when we use a monolithic backend we can get all data that we need in a single request, but in a microservices architecture this data is distributed in different services, for example, in a e-commerce web site it could be necessary getting data from inventory, pricing, user cart and so on, without the API Gateway the client would access each service separately, but the API Gateway can act as an aggregator, combining the response of these various services. This is just a sample of what an API Gateway can do, but it goes far beyond that.

An API Gateway has three main functions:

It acts as a reverse proxy, routing requests to one or more backend services. The gateway provides a single endpoint for clients and helps to decouple clients from services.
It acts as a request aggregator, we can use it to aggregate multiple individual requests into a single request, as shown in the e-commerce example I presented above.
Offload cross-cutting concerns from individual services, avoiding each backend service handling it by its own, some examples of functionality could be SSL termination, Authentication, Rate limit and Web Application Firewall (WAF), without the API Gateway whose services would be responsible for implementing those concerns, but with API Gateway these implementation will be offloaded to it.

Let’s dive deeper into each of these three functions.

Reverse proxy

To explain the reverse proxy we are going to start talking about the forward proxy. A forward proxy acts as an intermediary between a client and a resource, giving a simple example, when we use a proxy all the requests that your machine makes go through this proxy first before actually reaching the internet, providing a valuable layer of security for your computer.

The reverse proxy, as the name implies, does exactly the opposite of a proxy, it acts as an intermediary between the internet and our servers, providing a valuable layer of security for our services by shielding services from direct exposure to the internet:

The reverse proxy acts as an intermediary for client requests, it routes requests to appropriate services using a single endpoint and provides benefits such as SSL termination and caching. Imagine a client who needs to consume multiple services, continuing with the e-commerce example, imagine all the services that must be consumed such as inventory, reviews, cart and pricing. Each service has a different API that the client must interact with, and the client must know each endpoint to connect to the services. The reverse proxy abstracts the backend services from the client, allowing us to keep the client calls simple while allowing changes to the backend services behind the gateway. Client calls can be routed to appropriate services, allowing us to add, split, and rearrange behind the gateway without the customer changes.

The reverse proxy can be very useful too when our services run in several instances, imagine that a service is running in two different instances, it would be necessary for our clients to know these two instances and if we decided to scale out to four instances it would be necessary to change our client adding these new URLs, however with the gateway our client only needs to know one endpoint and the responsibility of knowing our instances is on the side of the reverse proxy.

Aggregator

We can also use our api gateway to aggregate several requests into one, this point is very useful when our client needs several services to complete a task, such as displaying all the information on a screen, for example, this chattiness between a client and a backend can adversely impact the performance and scale of the application, this can be solved through our gateway that will receive only one request from our client and it will dispatches request to the various services, and them aggregates the results and sends them back to the requesting client.

Offload cross-cutting concerns

Some features may be common between services, our API Gateway can help us by centralizing some of these features and offloading our services from deal with it on its own, this includes SSL certificate management, where we can configure our API Gateway with the certificate so that the client has an encrypted traffic but it is not required this certificate management for our services that are private and are not accessed directly from the internet. Our API Gateway can also be responsible for the authorization, it can validate client’s token ensuring that it is valid, our gateway can also have other functionalities such as authentication, logging, or monitoring.

Building our API Gateway

To build our own API Gateway we will use Ocelot, which is a simple, capable and lightweight API Gateway suitable for production-level scenarios. Ocelot is an open source API Gateway based on .NET Core made especially for microservices architectures that need unified entry points into their systems. It’s lightweight, fast, scalable, and provides routing and authentication, among many other features.

Ocelot also offers a request aggregation feature, but we will develop our own aggregator obtaining a more flexible solution, so we will create a dotnet Web API project that will be responsible for aggregating some requests, the aggregation project will access the other services through gRPC calls. We will have the following scenario:

API Gateway (Ocelot + Aggregator) + Services

There will be only a single entry point which is our Ocelot project, which means that all access from the outside world will go through it, we will map all valid routes in it, this way, when receiving a new request, Ocelot will be able to:

Forward to the Aggregator service
Forward to the Basket service
Forward to the Product service

Requests that require information from more than one service will be forwarded to the aggregator service, to obtain this data the aggregator service will call each necessary service using gRPC.

Conclusion

More and more I have seen people talking about API Gateways, as I said at the beginning, this is a pattern that has become quite popular as microservices architectures have gained more popularity too, in this article I tried to explain about API Gateways and show its benefits, in my next article I will implement our API Gateway (Ocelot + Aggregator) and the other two services (Basket and Product), if you liked the theme and my article, follow me so you don’t run the risk of losing this second part.

As I said before, we are going to use gRPC to communicate from the aggregator to other services, you can read my other article explaining and giving some examples about this.

Thank you for reading and feel free to contact me if you have any questions.