A 28+ app Vue platform, built and evolved since 2021
Context
This is a B2B2C platform built for a catering enterprise in Germany. Since 2021, I have been leading the frontend team working on it. The platform has grown into an ecosystem of more than 28 Vue applications orchestrated with single-spa, with GraphQL, REST and SignalR used across the system.
What makes the project interesting is not just the number of applications. It is the fact that the same platform has been evolving for more than five years. Architectural decisions that looked reasonable at the beginning have had to keep working as the product, the team and the number of applications grew.
How the applications work together
The micro-frontends communicate through an event bus built on
window.dispatchEvent. It is wrapped in a dedicated SDK package
used by every application, giving the platform one consistent interface for
browser-level communication between micro-frontends.
The same platform also combines several data and communication patterns: GraphQL through Apollo, REST APIs and SignalR for real-time updates. Keeping those pieces predictable across more than 28 applications is one of the ongoing architectural challenges of the platform.
What I have built and led
- Frontend team. I lead the team responsible for the Vue micro-frontends and the frontend architecture around them. That includes day-to-day technical decisions as well as mentoring developers and helping keep the architecture understandable across the team.
- Shared component library. I designed and shipped a Vue component library in Storybook. It gives the applications a shared implementation for recurring UI patterns, reducing duplicated component work and making the interface more consistent across the platform.
- Isolated development environments. I used Docker and Kubernetes to provide isolated environments for developers instead of forcing feature work into one shared environment. This made it possible to work on changes independently without competing for the same development setup.
- CI/CD. I worked on the Azure CI/CD pipelines for the micro-frontend ecosystem together with the DevOps team, helping make independent application delivery practical at this scale.
What becomes difficult at this scale
Running one frontend application is mostly a software problem. Running more than 28 applications that form one product is also a coordination problem. Small inconsistencies in naming, communication, dependencies or UI patterns can spread surprisingly quickly.
That is why the platform relies on shared contracts, reusable infrastructure and development rules that make the common path easy to follow. The goal is not to centralise every decision. It is to make the decisions that affect all applications explicit, while leaving individual teams enough freedom to work independently.
This becomes especially important when the platform has to evolve for years. The architecture needs to be understandable to developers who were not there when its original decisions were made.
The platform beyond the architecture
Over the years, the same platform has also produced some useful lessons outside the micro-frontend architecture itself.
One large Vue 3 rewrite became a performance problem before it reached production. I traced request waterfalls, duplicated work and inefficient data flows, then redesigned the data layer and real-time invalidation. The full story is in the performance rescue case study.
In another investigation, a surprisingly high projected translation cost in the cloud led me to trace thousands of unnecessary API calls through the development environment. The resulting change reduced paid translation API calls by 99.9%. That case is described in the translation cost case study.
What this platform taught me
Micro-frontends are relatively easy to demonstrate in a proof of concept. The interesting part starts later, when the system has to keep working as more applications, developers and years of maintenance are added.
Working on the same platform since 2021 has given me experience with that part: defining boundaries, maintaining shared infrastructure, supporting independent delivery and dealing with the performance and operational problems that appear once the architecture becomes large enough.
That is also why I start micro-frontend work by looking at the problem the architecture is supposed to solve. The full approach is described on the micro-frontends service page.
Stack
Vue 3, single-spa, TypeScript, GraphQL (Apollo), SignalR, Tailwind CSS, Storybook, Docker, Kubernetes, Azure CI/CD.