Microservices for Front Ends: How to apply microservice thinking to the browser – key takeaways from Michael Eder (Objectbay)

The missing evolution: microservices in the backend, a monolith in the browser

Backends have evolved from monoliths to SOA to microservices. In contrast, the frontend often remains a single, tightly coupled monolith. In his talk “Microservices for Front Ends,” Michael Eder (Objectbay) argued that it’s time to bring microservice principles to the user interface with micro‑frontends.

Eder pointed to the origin of the term: ThoughtWorks featured micro‑frontends in the Technology Radar in 2016, and companies like Amazon had already applied the idea in practice. He also mentioned Zalando, Spotify, HelloFresh, and Datsen as large adopters that assembled many UI parts into a coherent application users perceive as one product.

His core argument: frontends deserve the same decoupled, team‑autonomous architecture we expect on the server side. That calls for a few deliberate technical and organizational choices.

Who spoke and the backdrop

Michael Eder is a Full‑Stack Software Engineer at Objectbay. The company has been around since 2006, runs three locations (Traun as HQ, plus Vienna and Salzburg), employs roughly 50+ people, and has delivered 160+ projects. On the technology side, Objectbay works primarily on the JVM stack (Kotlin, Java), with Spring and Quarkus, but also runs projects outside Java—for example Python in an airport security context. The pattern is clear: diverse technologies, multiple industries, the stack that fits the domain.

At the start, Eder thanked Michael Gerst for allowing him to use visuals from the book “Micro Front Ends in Action”—a backdrop that became visible several times in the session, such as the “Tractor Store” example.

The gap to close: a modern backend behind a legacy‑style frontend

Eder recapped the well‑known trajectory: Monolith → SOA → Microservices. With each step, services became more fine‑grained, databases were split, and ownership sharpened. One thing, however, stood out to him: the frontend stayed monolithic.

The proposed answer is micro‑frontends: domain‑oriented, independently deployable parts of a UI that are assembled into a single product without visible seams for the user. The ideal target is clear: autonomous teams, independent CI/CD pipelines, potentially different technologies—yet a coherent experience.

The mental model: page ownership, fragments, and a unified product

Using the “Tractor Store” example (from “Micro Front Ends in Action”), Eder described a practical split:

• Page ownership: each team owns a page or domain end‑to‑end.
• Fragments: pages embed building blocks from other teams (e.g., recommendations, a buy button, a banner).
• Composition: many small pieces form a cohesive whole.

The decisive point: teams ship independently while the application still feels like a single product.

Organization first: cross‑functional teams, not layered silos

Architecture only works if the organization supports it. Eder emphasized that micro‑frontends thrive with cross‑functional teams—units that own everything from database to design, including architectural decisions and production monitoring. A DevOps mindset is implied.

He explicitly warned against introducing large, shared teams (for example a central infrastructure team) that take on wide responsibilities for everyone. That reintroduces coupling and dependencies between product teams and undermines the promise of micro‑frontends.

Instead, slice responsibilities per team and keep shared areas to a minimum.

Three cross‑cutting concerns every team must own

• Web performance: each fragment can slow down a page—performance is a team responsibility.
• Design system: a unified look and feel avoids UX friction and context switches for users.
• Knowledge sharing: in cross‑functional teams, knowledge has to flow continuously (e.g., chapters/guilds or focused groups on DevOps, architecture, clean code, testing/integration).

The three pillars of a micro‑frontend architecture

Before adopting micro‑frontends, Eder suggested answering three foundational questions:

1) Routing between applications: how do we implement page transitions without breaking the experience?

2) Composition: how do we embed micro‑frontends into a page?

3) Messaging: how do pages and fragments communicate?

He then laid out several practical options in each area—from trivial starting points to high‑performance solutions tailored to demanding use cases.

Pillar 1: Routing strategies—from plain links to an application shell

Hyperlinks: trivial, but with visible seams

The simplest approach is to navigate between applications via hyperlinks. It works, but UX is impacted (e.g., the URL changes, making context switches obvious). For anything beyond a prototype, it’s a compromise.

Reverse proxy (e.g., Nginx): unified domain, fewer CORS issues

A more elegant option is placing a reverse proxy between the client and applications. Eder called out Nginx as an example. Benefits include:

• A unified domain so the app feels cohesive.
• CORS headaches are reduced—even for CSS and JavaScript assets.

It’s a quick win that significantly improves user experience over plain hyperlinks.

Application shell: a meta‑framework for Single‑Page Applications

If you already use frameworks like Angular, Vue, or React, it pays to introduce an application shell. The shell loads and orchestrates multiple SPAs, keeping navigation inside a single document. Benefits:

• The browser stays in the same document; only content is swapped.
• Client‑side navigation cuts server round trips and can feel much faster.

In short, leverage SPA advantages holistically rather than per application.

Pillar 2: Composition—how micro‑frontends get into the page

iFrames: strong isolation at a cost

Eder acknowledged the usual reaction with a smile—“oh no, iFrames”—but made the case that they are relevant. Pros:

• High isolation: no CSS leaking, minimal cross‑impact between teams’ code.

Cons:

• Each iFrame creates a new web context, costing CPU and memory.
• Managing width/height becomes your problem.

AJAX: DOM embedding and better accessibility

AJAX can offset iFrame downsides. By embedding directly into the DOM:

• Screen readers understand the context (better accessibility).
• Natural flow removes manual size management.

The trade‑off is clear: if the server is unavailable, the fragment won’t render. Even so, AJAX remains a proven way to embed components elegantly.

Client‑ and server‑side integration: Web Components, SSI/ESI

Eder called out mixing client‑ and server‑side strategies. On the client, Web Components offer:

• Shadow DOM for strong isolation (akin to iFrame separation within the DOM world).
• Templates for reusable elements exposed via JavaScript and custom HTML tags.

On the server, he mentioned established techniques like Server‑Side Includes (SSI) and Edge‑Side Includes (ESI), supported by reverse proxies such as Nginx or Varnish. The pattern: placeholders in templates that the server fills with fragments. Advantages:

• Users receive a fully rendered HTML page.

He also noted that server‑side includes could theoretically execute unwanted code—something to address with sound security and process controls.

Taylor (Zalando, Project Mosaic): streaming composition for e‑commerce speed

Eder spent extra time on Taylor—Zalando’s streaming composition engine within Project Mosaic. The driver is clear: in e‑commerce, users should “see something immediately,” or they might choose a competitor. Taylor addresses this with a streaming API and a flexible template/fragment setup.

Key characteristics as summarized by Eder:

• Placeholders in templates filled by fragments.
• Streaming: the server sends content right away; the browser renders immediately; fragments load in parallel and are inserted as they arrive.
• Retry logic: define how often to retry when a fragment isn’t available yet.
• Fallbacks/redundancy: if one server doesn’t deliver, a second can serve the fragment.

The payoff is early first paint combined with robust fragment delivery.

Pillar 3: Messaging—clear channels between parent and fragments

Micro‑frontends need predictable communication patterns. Eder separated three directions:

1) Parent → fragment: pass data in

2) Fragment → parent: raise events upwards

3) Fragment ↔ fragment: cross‑context communication

Parent to fragment: properties and attributes

In the Web Components context, you pass data via properties/attributes. The parent configures the fragment by setting values directly—a straightforward, reliable pattern.

Fragment to parent: JavaScript events that bubble

Fragments can fire events that bubble up the DOM. Any element listening can handle them. This native web pattern fits micro‑frontend communication perfectly.

Fragment to fragment: Broadcast Channel API as a native message bus

Eder highlighted the Broadcast Channel API. It opens a message path between contexts on the same origin—for example windows, tabs, or iFrames. Practically, fragments can exchange data over topics without building tight direct dependencies.

Quality bar: performance, consistency, autonomy

Eder’s priorities are explicit:

• Performance: each fragment must be as fast as possible to avoid slowing a page.
• Consistency: a design system ensures a unified look and feel so the app never feels like a patchwork.
• Autonomy: teams should work end‑to‑end (database to design, including monitoring) and deploy independently.

Those goals reinforce each other. They become achievable when organization and technology align—without re‑introducing central bottlenecks.

A decision compass for teams adopting micro‑frontends

From Eder’s perspective, choosing the right approach comes down to a few honest questions:

• Do we need to hide context switches and unify the URL? If yes, consider a reverse proxy or an application shell.
• How much isolation do we need? iFrames provide maximum separation (CSS, context) at a CPU/memory cost.
• How critical is early rendering? If “users must see something immediately,” a streaming approach like Taylor is attractive.
• How often do fragments need to communicate? If frequently, establish a messaging concept early—events and the Broadcast Channel API are solid building blocks.
• How do we guarantee consistency? A design system and clear performance budgets are non‑negotiable.

These options are composable. Many successful setups combine several: an application shell for client‑side navigation and server‑side placeholders for fast initial rendering, for instance.

What “Microservices for Front Ends” made crystal clear

• Micro‑frontends are a pragmatic answer to the frontend monolith. They bring microservice thinking to the UI with real team autonomy and independent deployments.
• Adoption is primarily an organizational move: cross‑functional teams, DevOps mindset, clear end‑to‑end ownership.
• The architecture rests on three pillars: routing, composition, and messaging—each with multiple tried‑and‑true patterns, from hyperlinks to streaming engines.
• Performance and consistency are top‑tier concerns. Every fragment must treat them as first‑class.
• The toolbox is mature: reverse proxies (e.g., Nginx), application shells, iFrames, AJAX, Web Components, SSI/ESI—and for demanding streaming use cases, Taylor (Zalando/Project Mosaic) with retries and fallbacks.
• For fragment‑to‑fragment communication, the native Broadcast Channel API can serve as a lightweight message bus.

Conclusion: micro‑frontends are an organizational promise, not just a technical pattern

“Microservices for Front Ends” underscored that micro‑frontends are less about a pet framework and more about an organizational promise. When teams own features end‑to‑end, ship independently, and still deliver a consistent UX, the result is what matters most: faster value for users—without them noticing how many moving parts are behind the scenes.

As Eder put it, all the individual pieces are assembled and “a complete product” is delivered so that users “have no idea what’s behind it and feel like it’s one application.”

That’s the bar to meet. The building blocks are on the table—from hyperlinks to Taylor. The work is to combine them thoughtfully, slice responsibilities wisely, and make performance and consistency non‑negotiable. When you do, micro‑frontends turn from a buzzword into practical leverage for product delivery.

• 

  

  Serverless Applications with AWS Lambda

  Thomas Jäger von Objectbay geht in seinem devjobs.at TechTalk zu dem Thema Serverless Applications in die Tiefe und überprüft, ob die Marketing Slides von Amazon auch halten was sie versprechen.

  Watch now
• 

  

  Die Wahl der richtigen Software Architektur

  Alexander Knapp von Objectbay beschäftigt sich in seinem devjobs.at TechTalk mit der Herangehensweise, wie man aus einer Vielzahl an verschiedenen Software Architekturen die passende auswählt.

  Watch now
• 

  

  Mutation Testing

  Alexander Knapp von Objectbay widmet sich in seinem devjobs.at TechTalk dem Thema Mutation Testing – was es ist und wie jedes Software Projekt davon profitieren kann.

  Watch now

• 

  

  Alexander Knapp, Full Stack Software Engineer bei Objectbay

  Alexander Knapp von Objectbay schildert im Interview seinen Werdegang bis hin zu seiner aktuellen Rolle im Full Stack Engineering und was seiner Meinung nach für Beginner wichtig ist.

  Watch now