Microservices are the hot backend architecture: small, independent services instead of monolithic applications. The benefits—independent deployment, technology diversity, team autonomy—are compelling. But most SPAs remain monolithic. We're distributing the backend while keeping the frontend as one large application. Should frontend be microservices too?
The Microservices Backend Pattern
A typical microservice architecture:
- User service handles authentication
- Product service manages catalog
- Order service processes purchases
- Search service provides… search
Each service is independent: separate codebase, separate deployment, separate database. Services communicate via APIs. Teams own services end-to-end.
This works well for backend. But frontend is usually one application consuming all these services. The SPA knows about users, products, orders, and search. It's a distributed backend with a monolithic frontend.
Why Frontend Stays Monolithic
Several reasons frontend remains unified:
Browsers load one application. Unlike servers where you can run multiple processes, browsers download one bundle. Even if your frontend is conceptually separate applications, users load it as one artifact.
Shared UI components. Header, navigation, footer—these span all "services." You don't want the header team, navigation team, and footer team deploying independently. UI consistency requires coordination.
Routing is global. URL routing happens at the application level. You can't have the user service handle /users/* and product service handle /products/* independently in the browser.
Shared state. User authentication state, shopping cart, notifications—these cross service boundaries. Managing this in a distributed fashion in the browser is complex.
Approaches Being Tried
Despite challenges, teams are experimenting:
Separate SPAs per domain
users.example.com -> User management SPA
shop.example.com -> Shopping SPA
admin.example.com -> Admin SPALiterally separate applications. Works when domains are truly independent, but navigating between them means full page loads and state doesn't transfer.
iframes (yes, really)
<iframe src="/user-app"></iframe>
<iframe src="/product-app"></iframe>Each iframe is an independent application. They're isolated but can communicate via postMessage. This feels like regression to pre-SPA architectures, but it does enable independent deployment.
Lazy-loaded modules
// Main app loads minimal code
// Features load on demand
require.ensure(['./user-module'], function(UserModule) {
// User module loaded
});One SPA, but features are separate bundles loaded on demand. This is microservices-lite: modules can be developed independently but share runtime.
Web Components as service boundaries
<user-profile user-id="123"></user-profile>
<product-list category="electronics"></product-list>Each component is owned by different teams, deployed separately. The main app composes them. This is promising but Web Components aren't mature enough yet.
The Team Autonomy Challenge
Microservices aim for team autonomy: teams can deploy services independently without coordinating. Frontend makes this hard.
If the User team wants to change their UI, they can't just deploy. They need to ensure:
- UI changes don't break other teams' components
- Shared UI library changes are coordinated
- Design system compliance is maintained
- Build process changes don't break other teams
This coordination overhead reduces the autonomy microservices promise.
The Bundle Size Problem
Separate frontend services mean:
- Each service has its own copy of React/Angular/etc
- Shared utilities are duplicated
- Common dependencies (lodash, moment, etc) are replicated
Users download the same code multiple times. This kills performance.
Solutions like systemjs and import maps could help share dependencies, but they're not ready yet. For now, microservices frontend means larger bundle sizes or complex build coordination.
When It Might Make Sense
Frontend microservices could work for:
- Truly independent applications (admin vs customer-facing)
- Large enterprises with multiple frontend teams
- Applications willing to accept page transitions between services
- Companies prioritizing team autonomy over performance
It doesn't make sense for:
- Typical SPAs where features are integrated
- Performance-critical applications
- Small teams (overhead isn't worth it)
- Applications requiring seamless navigation
The Monorepo Alternative
Instead of separate repositories (true microservices), some teams use monorepos:
- One repository
- Multiple packages/modules
- Shared build infrastructure
- Coordinated releases
This gives modularization without distribution overhead. Teams own modules, but there's central coordination. It's a middle ground between monolith and microservices.
Looking Forward
The mismatch between distributed backend services and monolithic frontend creates tension. But forcing microservices patterns onto frontend might create more problems than it solves.
My take: the real frontend architecture challenge is managing complexity in large SPAs. Microservices solve this on backend by distribution. Frontend needs different patterns—maybe better module systems, lazy loading, component architectures, or build tools that handle large codebases well.
Microservices frontend exists more as aspiration than reality. The browser's constraints—single origin, single bundle, global state—fight against distribution. Until those constraints change (Web Components? Import maps? Something else?), frontend will remain more monolithic than backend.
That's not necessarily bad. Monoliths have benefits: simplicity, performance, easier testing. The question isn't "should frontend be microservices?" It's "what's the right level of modularization given frontend constraints?"
And that answer is probably somewhere between strict monolith and true microservices.
Resources:
- Microservices by Martin Fowler – Backend pattern
- Micro Frontends – Emerging pattern (note: site from future, concept exists now)
- SystemJS – Universal module loader
