<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Micro-Frontends on Adrian Spiridon</title><link>https://adrianspiridon.dev/tags/micro-frontends/</link><description>Recent content in Micro-Frontends on Adrian Spiridon</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Sun, 21 Jun 2026 00:00:00 +0300</lastBuildDate><atom:link href="https://adrianspiridon.dev/tags/micro-frontends/index.xml" rel="self" type="application/rss+xml"/><item><title>Micro Frontends Architecture Guide</title><link>https://adrianspiridon.dev/blog/micro-frontends-architecture-guide/</link><pubDate>Sun, 21 Jun 2026 00:00:00 +0300</pubDate><guid>https://adrianspiridon.dev/blog/micro-frontends-architecture-guide/</guid><description>&lt;div class="paragraph"&gt;
&lt;p&gt;Choosing a technology stack or integration pattern is rarely a neutral decision. In large enterprises, ideas like Micro Frontends can easily become the default answer through inertia: they sound modern, they promise reuse and autonomy, and teams are often expected to adopt them before the real costs are understood.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="paragraph"&gt;
&lt;p&gt;This guide is about slowing that decision down.&lt;/p&gt;
&lt;/div&gt;
&lt;div class="paragraph"&gt;
&lt;p&gt;Micro Frontends can be the right architecture, but only when the need for runtime composition and independent frontend deployment is real. Otherwise, a simpler modular frontend design — using libraries, clear boundaries, lazy loading, and a well-structured monorepo — may provide most of the benefits with fewer operational headaches later.&lt;/p&gt;
&lt;/div&gt;</description></item></channel></rss>