Waking the server…
It naps when nobody’s around. Give it a few seconds.
DemiWaking the server…
It naps when nobody’s around. Give it a few seconds.
Tutorials, architecture notes and lessons learned from building real applications.
When I was building a C# desktop application, I wanted updates to just work — no installers, no manual steps, no friction. Here's how I used Velopack and GitLab Releases to make it happen.
Micro-frontends and serverless backends solve different problems. But the boundary between them? That's where most architectures fall apart. Here's what actually worked when building a compliance-critical competence management platform — and what didn't.
Most developers see pages to build. I see component systems. While working on a large-scale **enterprise learning and competence management platform**, I spent significant time implementing a shared UI component library that my team later took governance of. Through that work, I learned this: **Component-level thinking isn’t about React or Vue — it’s about seeing patterns instead of pages.** Here’s why your frontend architecture matters more than your design, and how thinking in components separates maintainable codebases from maintenance nightmares.
Micro frontends (MFEs) promise to change how we build and scale frontend applications. The idea is compelling: break a monolithic frontend into smaller, independently developed and deployed pieces owned by different teams. In practice, though, MFEs are still finding their footing. After building and prototyping micro frontend architectures on a large-scale **enterprise learning and competence management platform**, I learned why adoption remains slower than the hype suggests. The biggest blocker isn’t team structure or tooling maturity — it’s **dependency coupling**, most often hiding in plain sight inside `package.json`. This is what actually holds many MFE implementations back, and what worked when we started addressing it.
I share every new article on LinkedIn first.