This is a placeholder post. It exists to exercise the rendering pipeline — headings, lists, code, tables, blockquotes — so replace it with something you actually want to say.
Why static server-side rendering
Blazor offers three render models. This site uses static SSR only: no interactive render mode, no SignalR circuit, and no WebAssembly runtime download. Every page arrives as HTML.
That is not asceticism. The site's job is delivering text to readers and crawlers, and the only genuinely client-side behaviour is the theme toggle — about sixty lines of vanilla JavaScript. Adding a rendering mode to power one button would be a poor trade.
The consequence worth naming: static SSR needs a server, which rules out the Azure Static
Web Apps free tier and pushes hosting onto Container Apps, where scale-to-zero means the
first request after an idle period is slow. That trade is written up in docs/adrs/.
How posts work
A post is a Markdown file with YAML front matter:
---
title: Building this site with Blazor static SSR
date: 2026-07-30
tags: [dotnet, blazor, architecture]
---
At startup, the application reads every *.md file, renders it with Markdig, and builds
an immutable index:
services.AddSingleton<IPostCatalog>(sp => new PostCatalog(
sp.GetRequiredService<IPostSource>(),
sp.GetRequiredService<IPostParser>(),
sp.GetRequiredService<IPostCatalogObserver>()));
Serving a page is then a lookup against a FrozenDictionary. No disk I/O, no Markdown
parsing per request.
A post that fails to parse is logged and skipped rather than thrown. Posts load at startup, so an exception would turn one front-matter typo into a crash-looping revision. A missing post is a visible absence; a dead site is an outage.
The layers
| Project | Depends on | Holds |
|---|---|---|
Domain |
nothing | Post, PostSlug, Tag, ReadingTime |
Application |
Domain | ports and PostCatalog |
Infrastructure |
Application | Markdig, YamlDotNet, file system, RSS |
Web |
Application, Infrastructure | Blazor components, composition root |
Four projects is more ceremony than "read some files and render Markdown" strictly needs, and that tension is worth being honest about. What it buys is that the volatile parts — the Markdown engine, the storage mechanism, the front-matter contract — each sit behind a single interface, and the interesting logic is testable without a web host or a file system.
What is next
- Replace the placeholder CV content in
StaticProfileSource - Write a post that demonstrates something specific rather than describing the site
- Wire the custom domain once the Container App is provisioned