Coding With David

 “You didn’t decouple EF Core. You just hid it badly.” I’ve built this architecture. More than once. Early in my Blazor projects, adding repository abstractions felt like the responsible thing to do. The code looked clean. The layers were clear. Code reviews were easy. Then the app grew. The team changed. Performance started to matter. That’s when the repository layer stopped helping—and started getting in the way. This article isn’t about theory. It’s about what I’ve learned the hard way, maintaining long-lived Blazor applications. Why I Used Repositories (And Why They Felt Right) I didn’t introduce repositories because I was careless. I did it because: Books recommended them Talks showcased them Juniors expected them “Clean Architecture” diagrams normalized them And early on? They worked. That’s the trap. The Year-Two Problem The pain never shows up in month three. It shows up when: Queries need tunin...

  If your Blazor app works locally but breaks in Azure, there’s a good chance configuration is the real bug. Blazor developers often treat configuration as a startup concern —something you wire up once and forget. That works… until you add environments. or feature flags. or secrets. or a second app. Then the configuration quietly turns into a distributed liability . Let’s talk about why hardcoded AppSettings patterns don’t scale—and a cleaner, environment-aware approach that actually survives real projects. The Common (But Fragile) Pattern Most Blazor apps start like this: // appsettings.json {   "InCounter": 5,   "FeatureFlagStyleTable": true } Var styleTable = configService.Value.FeatureFlagStyleTable; At first, this feels fine. Then you add: appsettings.Development.json appsettings.Test.json appsettings.Production.json Azure App Service settings Feature flags Secrets in Key Vault Suddenly: ...

  The uncomfortable truth After decades of building enterprise systems, here’s an observation that makes some people uncomfortable: Most people who ask for “real-time” data updates don’t actually need real time. What they want is confidence , responsiveness , and trust — not millisecond precision. And yet, the moment the phrase real time enters a requirements meeting, costs go up, architectures get complicated, and teams quietly inherit a system they now have to babysit forever. What people say vs. what they actually mean When someone says: “We need this data in real time.” They usually mean: “I don’t want stale data.” “I don’t want to refresh the page.” “I want to react quickly.” “I want to trust what I’m seeing.” None of those requires true real-time infrastructure. They require fast-enough data and good UX . Once you cross into true real time , you introduce: Persistent connections Stateful servers Fan-out scaling challenges Reconnection logic O...