My experience with Ocelot as an entry point to an app was mostly good. I like that it is cloud-agnostic – it’s good to go on Azure, AWS, or whatever.

The biggest issue I had was with route configuration. You are stuck writing a static config file (separate from appsettings.json) or creating an overkill provider.

In my dev environment, I used Ocelot’s config file and my routes all pointed to localhost. But when deploying to the cloud, did I really want to create another config file (ocelot.production.json) just for a different hostname or port? My solution was to dynamically build the routes at runtime using injected ENV variables.

All of my integration tests often use Testcontainers to quickly spin up external dependencies like PostgreSQL or RabbitMQ. It’s very useful for creating a quick, production-like environment.

But I was running into an issue where the ports of these Docker containers were not freeing up on subsequent runs in my GitHub Actions build pipeline and would see errors indicating the ports were already bound by Docker.

The issue could only be recreated locally if the integration tests ended prematurely and allowed me to see containers weren’t properly being disposed.

This is a continuation of how to Serve a Single Page App (SPA) With ASP.NET Core. In that post, I explain how you can build your SPA and include the build artifacts when you run an ASP.NET Core app.

When it comes to deployment, if my backend is 100% in .NET, I would much rather skip deploying another container to run the UI. As described in my post, you can just include the static files from your SPA and ASP.NET Core will include them in its routing.

I’m used to deploying a Single-Page App (SPA) like React in its own container but for simple front ends whose back ends are 100% ASP.NET Core, there is a package Microsoft.AspNetCore.SpaServices.Extensions.

This package allows you to place the build artifacts of your SPA in your ASP.NET Core project. You can then run the ASP.NET Core app with controllers and routes, along with the SPA with its own routes. This is accomplished by reserving routes for both apps.

My most recent project has a few microservices in it and I wanted to report their job status to the UI. Since the microservices will be isolated from public access, I ended up creating an additional SignalR hub on my gateway app, which acts as the public entry point.

How does it work?

Each microservice in the isolated network has its own SignalR hub. Since a web client cannot connect to them, you just create a gateway hub in the gateway app using the library Microsoft.AspNetCore.SignalR.Client. Your Multiplexer class will then connect to each microservice’s hub and upon receiving a message from a microservice, will broadcast it using the gateway hub. Any web client will then just need to connect to the gateway hub to get real-time data from any of the microservice hubs.