API Gateway with Ocelot using .Net Core - Part 3 - Response Aggregation and Azure deployment

We have seen a simple API Gateway setup in the previous article. Let us see the steps in setting up API Gateway for Response aggregation and also see how to deploy it in Azure.

Response Aggregation is required when your API Gateway needs to help/act as Backend For Frontend(BFF) pattern. Beyond being a reverse proxy and routing, at times we may need to expose responses from multiple apis (aggregate) instead of allowing clients to call multiple apis by themselves to do.

A simple Response Aggregation using Ocelot is done through the following steps

1. Continuing to previous article where we created Content.API project with content api, we will create one more simple api, Comment API as part of the Content API Project.
2. In our Ocelot project, in Ocelot.json, we will provide the upstream routing path from Ocelot API Gateway project to Content APIs.
3. Also, we will create a Response Aggregation endpoint in the Ocelot that is exposed to clients. The endpoint will aggregate the responses of Content and Comment API together as response.

Step 1 - Create additional API (Comment API)

I am not showing the actual code here as its simple and I know you can build a simple comment API.

In the launchSettings file, I deliberately commented the Https and changed the port of http to 5001 where the Content and Comment API will be exposed. For ex: https://localhost:5001/api/content will provide sample, hardcoded content data as response.

Step 2 - Change the Ocelot.json in the APIGateway project

The downstream host IP is updated to a public IP (we will see the reason shortly, however if you are trying this in local system, you can change it to "localhost").

Note that the gateway route path (upstream) https://localhost:5151/blog/content should route to https://localhost:5001/api/content and https://localhost:5151/blog/comment should route to https://localhost:5001/api/comment respectively.

The response of Content and Comment API will be aggregated (see the Keys parameter and RouteKeys parameter which determines the responses to aggregate).

Note : In older version of Ocelot documentation the "RouteKeys" are called as "ReRouteKeys". Please refer to Ocelot latest documentation always.

No change in the APIGateway project other than the Ocelot.json file (good thing right :) ).

Step 3 - Dockerize the API and APIGateway projects and push it to Docker hub

Now that we have created ContentAPI and APIGateway projects (ideally seperately to build separate docker images and push them to Azure in individual Container instances :) )

First, test the ContentAPI project locally to see if it works and then containerize the project.

Similarly test the APIGateway locally and containerize it.

Dockerfile of Content API Project

Similarly create a Dockerfile for APIGateway as well (just use the above one and change the project "Content.API" to "APIGateway" or whatever is the project name including the dll filename).

Note : Port 5001 is exposed in the dockerfile using EXPOSE command, however that alone is not working (for reason that I dont know and many people are trying to figure out why). So, instead of EXPOSE "PORTNO" add env variable as ENV DOTNET_URLS=https://+:5001 to ensure 5001 is exposed.

# Create Docker Build from the folder where Dockerfile is created
> docker build -t containerapiported:latest .

# Docker run to run the container. 
> docker run -d -p 5001:5001 --name containerapi containerapiported:latest

# After testing this container locally, let us push it to docker hub
# login to docker hub
> docker login

# Tag the image before pushing to Dockerhub
> docker tag containerapiported:latest rvwaran/containerapiported:latest

# Push the docker tag from local to docker hub. Check it in hub.docker.com to see if this pushed image is available in the public Repository
> docker push rvwaran/containerapiported:latest        

Similarly do the above for APIGateway as well. I have pushed the APIGateway image to rvwaran/apigatewayported:latest into docker hub.

Note : After the ContentAPI image from docker hub is deployed to Azure Container Instance and tested to see if the local call to the content and comment api works (like :5001/api/content and :5001/api/comment, we should get the public IP of that Content API container instance and update it in the Ocelot.json in APIGateway. Then follow the above steps to dockerize the APIGateway project.

Step 4 - Deploy to Azure

Now that we have the images of Content API (includes content and comment api) and APIGateway images in Docker hub public repository, let us deploy in Azure.

Note : Azure has multiple ways to deploy Container applications.

1. Web App for Containers (preferred to deploy web applications as container including DB and other services if required)
2. Container App (preferred for any container deployment, however it does not provide a public IP itself)
3. Container Instances (exposed public ip for us to access the instance directly). So, I chose this option (after trying everything else :) ) because the downstream path host can be replaced with the public IP of the Content API deployed as container.

Now you can recollect why there was a public IP (20.116.201.129) added to the Ocelot.json in APIGateway project.

The sequence of deployment is

1. Create a Container Instance for ContentAPI first and use the Public IP of that to update the Ocelot.json of APIGateway and
2. Create another Container Instance for APIGateway now.

Create Container Instance for ContentAPI

Go to Container Instance creation in Azure and fill the following

1. Resource Group - Create a Resource Group or choose an existing default one.
2. Container Name - Give a container name (like "containerapi")
3. Image Source - Choose the Image Source as Other Registry (for Dockerhub)
4. Image Type - Choose Public
5. Image - enter the docker hub image location with tag like "rvwaran/containerapiported:latest"
6. OS Type - Choose Linux or Windows (I chose linux)
7. Go to Networking and keep "Networking Type" as Public
8. In the Ports, make sure you delete default port 80 and add 5001 (This is the port which is exposed by the container. So, in the host instance where we are deploying this container now should be able to map it to 5001. Unfortunately there is no way to specify the host port : container port mapping here. So, we cannot use any other port other than the one exposed in the dockerfile through ENV which is based on the launchSettings of the project)

NOTE : if you use default port 80 to map the ContentAPI, container did not start. Port 80 is not allowed for container mapping. That is also a reason why you should expose the API through a different port (here 5001) and expose the port in Dockerfile and mention the exposed port in the Ports parameter as above.

Wait for the container instance to be up. Test it by hitting https://<publicIPaddr>:5001/api/content (as shown below) and check comment api as well.

Create Container Instance for APIGateway

Follow the same steps done for ContentAPI Containerization. Provide the public image from docker hub for apigateway (in my case rvwaran/apigateway:latest).

Provide the Port to expose as 5151 in the "Ports" parameter. Remove any other port if exposed.

Wait for the Container Instance to be up. Test it now.

https://<publicipaddr>:5151/blog/content should respond with https://<contentapi_containerinstance_publicipaddr>:5001/api/content as mentioned in the Ocelot mapping.

Similarly https://<publicaddr>:5151/cms/blog should provide the aggregated response of both Content and Comment API as given below.

Note : Carefully look at the response payload to see "content" and "comment" API responses collated/aggregated below.

Hope this helps !!! Happy coding.