Newest first, grouped by year. Search or filter by topic.
Trill's Blazor WebAssembly client has twenty Razor components, thirty-seven inline style attributes, two authored class names and one stylesheet containing a single rule - and the thinness is not an oversight, it is the most precise measurement of what a teaching repository is.
DShop.Blazor is a Blazor 0.7 preview app whose naive choices - component classes as singletons, a silent auto-signup, a shared HttpClient - all work because of the runtime they run on. A study in patterns that are only correct by accident.
DShop has an Angular 6 SPA and a Blazor 0.7 WASM app over the same gateway. One has the right architecture and broken plumbing; the other has naive architecture and a working shop. The contrast is the lesson.
DShop runs a whole SignalR service to push operation results to the browser in real time - JWT handshake, per-user groups, Redis backplane. No frontend connects to it, and both UIs sleep through eventual consistency instead.
In DShop a customer is born in two steps - a record on sign-up, then a completed profile. Following both across the monolith and the swarm shows how a consistency model quietly rewrites a user flow.
DevMentors built the same e-commerce shop twice - once as a monolith, once as nine services - with two gateways and two frontends. This series reads the whole estate as one artefact.
