How I Develop APIs

Wed, 21 Oct 2026 19:30:00 +0000

Every backend I build is an ASP.NET Core API, and they all look alike on purpose. When the structure is the same everywhere, I never have to remember where a thing lives, a new feature is a list of files to add rather than a design decision, and a test that fails points at one small piece of code.

This page describes that shape, using Heimdall as the example throughout. Heimdall is my identity management API: people, applications, logins, two-factor authentication and permissions, for several client systems at once, each in its own scope. It is the largest API I have, so every pattern here has been tested against a real use case rather than a toy one. All code on this page is taken from it, trimmed only where noted.

Web APIs

Wed, 21 Oct 2026 17:55:00 +0000

My backends are ASP.NET Core APIs, and every one of them meets the platform the same way. Heimdall’s API is the example throughout; Fortuna’s follows the same shape.

Concern	Choice
Framework	ASP.NET Core on .NET 10
Image	Multi-stage: the SDK to build, the ASP.NET runtime to run
Database	The host’s PostgreSQL, one database per environment
Configuration	Environment variables, from yggdrasil
Health	`/healthcheck`, probed by Docker, yggdrasil and the status API
Metrics	OpenTelemetry’s Prometheus exporter, on port 9464
Logs	Standard output, shipped to Loki
Checks	Tests and a Docker build in GitHub Actions

The image

The Dockerfile has two stages. The first restores and publishes with the .NET 10 SDK, copying the project files before the sources so a source-only change reuses the cached restore. The second copies the output onto the much smaller ASP.NET runtime image, and runs it as the image’s own non-root user:

ASP.NET Core on Artur Rios Lab

How I Develop APIs

Web APIs

The image