Micro frontends: when the best thing to share is the app itself

There is a question that comes up again and again between a team that produces data or capability and the teams that want to use it: what is the right way to hand it over? I have watched the answer change several times over my career, and each change moved the integration point a little higher up the stack. The latest step is micro frontends, and it is the one worth talking about.

The evolution I lived through

Nightly batch files, or direct database access. In the early model, the upstream team shared files on a schedule, or gave the consuming team access to a database, and the analytics team built a reporting layer on top. It worked, but the data was as old as the last batch, and every consumer rebuilt their own logic over the raw data.

Kafka streaming. Next, the data moved in near real time over a stream, and consumers built dashboards on top of it. Much fresher, but the consuming teams still owned all the processing and all the views they put on it.

APIs. Then the upstream team exposed the data through an API. That was a real improvement: a clean contract, and consumers no longer reached into raw storage. But every consumer still built its own interface and re-implemented its own interpretation of what the data meant.

Micro frontends. In the current model, the upstream team exposes the application itself as a service. A self-contained piece of interface, along with the logic behind it, that another system embeds directly into its own app. The consuming system now integrates the capability, not the raw data.

Why sharing the app is the step up

Look back at the first three stages and you notice the same tax at every level. The consuming teams kept rebuilding something: a reporting layer, then dashboards, then their own UI and their own reading of the data. That is duplicated data work, duplicated API work, and a steady source of inconsistency, because every team interprets and renders the data slightly differently.

A micro frontend collapses that. When the producing team exposes the app itself, it owns the data, the logic, and the presentation in one place, and other systems embed that piece rather than recreate it. The payoff is direct:

• Less duplicated work. Consuming teams stop building their own pipelines, APIs, and screens for a capability that already exists.
• Consistency by default. Everyone sees the same interface driven by the same source, so the data cannot drift between one team’s version and another’s.
• Faster integration. Standing up a capability inside an existing system becomes embedding a component, not running a months-long data and UI project.

The honest tradeoffs

Micro frontends are not free, and they are not always the answer. You take on runtime integration complexity, shared dependency and versioning concerns, performance considerations from loading remote interface pieces, and the work of keeping design consistent across different host applications. They shine when a capability is genuinely owned by one team and reused widely. For a simple data need, a plain API is still the right and lighter choice.

The takeaway

Integration keeps climbing the stack: files, then streams, then APIs, and now the application itself. Each move trades a little flexibility for less duplication and more consistency. Micro frontends are the current end of that line. When many teams need the same capability, sharing the app beats asking every one of them to rebuild it, and the time and consistency you get back are worth the integration cost.