It's been already 2 years since I stopped working on the AzUrlShortener project. Not that I didn't like it, but I was busy with other projects. Recently, the opportunity to work on it again came up, and I jumped on it. So many things changed in two years, and I was excited to see how I could improve the solution's developer experience and modernize the user interface and architecture.
This post is the first of a series where I share a few interesting details, tips, and tricks I learned while working on this project.
AzUrlShortener is an Open source project that consists of a simple URL shortener. The goal was simple: having a budget-friendly solution to share short URLs that would be secure, easy to use, and where the data would stay ours. Each instance is hosted in Azure and used to consist of an API (Azure Function), a Blazor WebAssembly website (Azure Static Web App), and Data Storage (Azure Storage table).
Key Changes at a Glance
- Migration from Azure Static Web Apps to Azure Container Apps
- Upgrade to .NET 9.0 and integration with .NET Aspire
- Enhanced security with separated API responsibilities
- Simplified deployment using Azure Developer CLI (azd)
- Modern UI with FluentUI Blazor
Upgrading SDKs and packages
As mentioned earlier, a lot changed in two years. The first thing I did was to upgrade the SDKs to .NET 9.0. That was a breeze; I changed the target framework in the project file then used dotnet-updated to list all the packages that needed to be updated. I then used dotnet outdated -u to update all the packages.
And while we were at it, since I started using .NET Aspire, I couldn't resist using it as much as possible. It simplifies the development cycle so much, and the code is much cleaner. So I added that to the mix. It added two more projects to the solution, but now the entire solution is defined in C# in the AppHost project (the Aspire orchestrator).
So now the solution looks like this:
src/
├── Cloud5mins.ShortenerTools.Api # Internal management API
├── Cloud5mins.ShortenerTools.AppHost # .NET Aspire orchestrator
├── Cloud5mins.ShortenerTools.Core # Shared business logic
├── Cloud5mins.ShortenerTools.FunctionsLight # Public redirect API
├── Cloud5mins.ShortenerTools.ServiceDefaults # Common service configurations
└── Cloud5mins.ShortenerTools.TinyBlazorAdmin # Frontend application
Changes to Improve Security
Security should come first, and I wanted to make sure that the solution was as secure as possible. I decided to split the API into two parts. The first part is the API that redirects the users, and it can only do that. The second part is the internal API to manage all the URLs and other data.
I decided to migrate the solution to use Azure Container Apps and have it running in two containers: the TinyBlazorAdmin and the Api. With Azure Container Apps, I can use Microsoft Entra, without any line of code, to secure TinyBlazorAdmin. The API will only be accessible from the TinyBlazorAdmin and won't be exposed to the Internet. As a bonus, since TinyBlazorAdmin and the API are now running inside containers, you could also decide to run them locally.
The storage access got also a security upgrade. Instead of using a connection string, I will be using a Managed Identity to access the Azure Storage Table. This is a much more secure way to access Azure resources, and thanks to .NET Aspire, it is also very easy to implement.
Architecture
The architecture is changing a little. The API is now split in two: FunctionsLight and API. The two APIs use services from Core to avoid code duplication. The TinyBlazorAdmin runs in a container and is secured by Microsoft Entra. API is also running in a container and is not exposed to the Internet. And Azure Storage Table is still our faithful data source.
Previous Architecture
- Azure Function (API)
- Azure Storage (Function Code)
- Azure Static Web App (Blazor WebAssembly)
- Azure Storage Table (Data)
- Application Insights
New Architecture
- Container registry (Docker images)
- Container Apps Environment
- Container App/ Function: FunctionsLight Public redirect-only API
- Container App: Internal API Protected management interface
- Container App: TinyBlazorAdmin Secured Blazor website
- Azure Storage Table (Data)
- Managed Identity
- Log Analytics
Deployment
The Deployment is also changing. Instead of using a button from my GitHub repo, we will be using the Azure Developer CLI (azd) or a GitHub Action from your own repo (aka fork). The deployment will take ~10 minutes and will be done with one simple command azd up.
The entire solution will still have Infrastructure as Code (IaC) using Bicep, instead of ARM.
Here a video about it
Were there any challenges?
While working, there were a few challenges or "detours" that slowed the progress of the migration a little, but most of them were due to decisions made to improve the solution. Let's take a look at the first one in the next post: How to use Azure Storage Table with .NET Aspire and a Minimal API (soon).
