Microservices API Gateways — Ocelot for .NET Core + Video

Ocelot API Gateway using ASP.NET Core, Mac OSX and Visual Studio Code

If you are building Microservices, you are going to need an API Gateway.

There’s quite a few API Gateways that can be used to manage your REST APIs. Here’s a few that we will cover in a series of posts that follow:

1. Ocelot — This is an open-source .NET Core API Gateway that is used by Tencent. We will be focusing on this gateway in this article.
2. Kong — This is also an API Gateway built on top of the popular Nginx server. This is a very robust platform which has a community edition as well as a paid Enterprise Edition.
3. Express API Gateway — This is an API Gateway built on top of the popular Express JS platform
4. Azure API Management — Azure API Gateway allows you to create a management layer that includes documentation, api gateways etc. among other things.

NOTE: In this article, we are going to focus our demo using a Mac OSX and Visual Studio Code. Another post will focus on a video with Visual Studio 2017 and Windows.

Why do I need an API Gateway?

You don’t need an API gateway. There are some talks of not using API Gateways because they represent a single point of failure (although I’m not sure how), but using a Gateway pattern sure simplifies things.

If you’re building a Microservices architecture, there’s a couple of different strategies you can follow. You can either have separate APIs that individual consumers need to be aware of, or you can present a unified API via an API Gateway.

If you’re presenting your API via a unified gateway, you’ll need an API Gateway platform.

Microservices Example — E-Commerce API

In our example here, we assume we’re building an E-Commerce API.

E-Commerce applications have a way of getting extremely complex. There’s Catalog/Product information, Shipping services, Tax services, Order services, Inventory management services, Email services, User management services etc.

The e-commerce domain is extremely complex to be constructed as a monolith. You could do it, but you could also have sleepless nights. ;)

Depending on the complexity of each of these services, you may decide to split them up into one or more microservices.

In our example, let’s keep things very simple and build an Orders API as well as Catalog API. These two will be sufficient to demonstrate the API Gateway — Ocelot.

Our general strategy will be like so:

1. We will build the Catalog API — Port 7001
2. We will build the Orders API — Port 7002
3. We will build the API Gateway — Port 7000
4. We will configure Ocelot
5. We will test the API Gateway

If you want to watch the video, it is here:

Ocelot API with ASP.NET Core 2.1 and VS Code/Mac OS X

Let’s get started.

Build Solution & Various APIs

The best way to build the a good structure is by having a solution that has multiple API microservices. You could have one solution per micro-service (depending on how your teams are structured), but for the sake of this demo, we will be building 1 solution with 2 Microservices and 1 API Gateway project.

This is the project structure I came up with:

Folder Structure for the API Gateway

Use the “dotnet new sln” command to add the solution. You should see a new solution created like so:

Create A Solution Using ‘dotnet new sln’

Once you have added the solution, you can add sub-folders for the various apis, e.g. “CatalogApi” and “OrdersApi”. You can navigate to the respective sub-folders and create the ASP.NET Core Web API projects by doing “dotnet new webapi”.

You can also add the projects to the solution using a VS Code Plugin for Solution Explorer as shown:

Add Existing Project To Solution (Solution Explorer Plugin)

Make sure your Catalog API runs on port 7001.

Catalog API on Port 7001

Make sure your Orders API runs on port 7002.

Orders API on Port 7002

Add The API Gateway

Once you’ve added these microservices, your next task involves adding the API Gateway. You can navigate to the “ApiGateway” folder and do a “dotnet new webapi” to add an ApiGateway project. Go ahead and delete the ValuesController. We don’t need it.

At this point, you need to do 2 things:

1. Add ocelot.json to give Ocelot directions for microservice redirects
2. Add Ocelot plumbing in the ApiGateway ASP.NET Core Web API Project

To add the configuration, simply add an ‘ocelot.json’ file. Now that you’ve added this file, you simply need to make sure your ApiGateway project knows about it. That can be done using the following lines of code:

Add ocelot.json to the App Configuration

Once that is done, you just need to add the Ocelot service as well as the Ocelot middleware. Your Startup.cs should look like so:

Add Ocelot Plumbing in Startup.cs

Once you do that, you can configure the ocelot.json like so:

Example of Microservice redirects using ocelot.json

The following are important things to note:

1. The GlobalConfiguration allows you to define the BaseUrl that Ocelot is going to listen to. In our case, we configured it to use localhost:7000
2. The ReRoutes array allows you to define one or more redirects. The downstream paths represent the paths to the microservices. The upstream paths represent how the users will access these microservices via the API Gateway.
3. You can do a wildcard redirect for each api by providing a variable name as shown. In our case, we’ve used a variable name {catchAll} that will catch all incoming traffic on catalog-api/ and redirect it to api/ on 7001 and orders-api/ and redirect it to api/ on 7002.

And that’s pretty much all you need.

You should be able to use your API gateway as shown in the video.