Scaling the Cliff: Transparent UI Macroservices
Two weeks ago, we introduced the concept of Zero-Cliff UI Composition. We shared our vision for a progressive architecture where your code remains the same whether it's a monolith or a distributed suite.
Today, we are taking the next step: UI Macroservice Decomposition.
Beyond the Virtual Environment
In our previous post, we mentioned that Framework M discovery was strictly local—limited to the current Python environment. This is perfect for "Indie" mode and modular monoliths. It provides a rock-solid, zero-config experience.
But as teams grow, so does the need for independent deployment. You might have a dedicated team for Inventory Management that wants to deploy their UI updates twice a day without touching the main Accounting host.
To support this, we’ve introduced two powerful features that bring "Level 5" deployment to everyone.
1. Config-Driven Network Discovery
We’ve evolved the Discovery API to be an aggregator. While it still prioritizes local Python entry points, it now listens for external configuration.
By setting FRAMEWORK_M_MFE_REMOTES or pointing to a JSON file via FRAMEWORK_M_MFE_REMOTES_FILE, you can register remote Micro-Frontends (MFEs) dynamically.
# Register a remote billing service
export FRAMEWORK_M_MFE_REMOTES='{"billing": "http://billing-service:8888/mfe/billing/1.0.0/remoteEntry.js"}'
The Shell Host now "knows" where your macroservices live across the network, enabling a unified dashboard that spans multiple servers.
2. The Transparent Proxy: The "Secret Sauce"
The biggest challenge with distributed MFEs is Origin Integrity. Browsers are (rightfully) suspicious of assets coming from different domains. CORS headers, SSL mismatches, and mixed-content errors are the "cliffs" that usually kill MFE projects.
Our solution? Transparent Proxying.
When you enable FRAMEWORK_M_MFE_PROXY_ENABLED=true, the Shell Host becomes a smart proxy for remote assets. When the browser asks for /mfe/billing/..., the Shell Host fetches it from the remote service and serves it as if it were local.
- Zero CORS Hassle: The browser only ever talks to the Shell Host.
- Internal Security: Your macroservices can stay private inside your VPC/Kubernetes cluster, while the Shell Host handles public delivery.
- Consistent DX: The developer experience remains "indie-simple" while the architecture is "enterprise-distributed".
The Bridge to Purity
In our first post, we spoke about Pure Headless as the ultimate scaling option. Today, we've made that option even more powerful. You no longer have to "eject" the UI to go pure. You can run your high-performance engines independently while the Framework M Shell Host keeps your dashboard unified and Zero-Cliff.
Pragmatic Scaling: Day 1 to Day 1000
In an "ideal" engineering world, scaling often implies a paradigm shift—rewriting critical paths in a lower-level language or moving to a pure async architecture.
But in the real world, you can't always force a rewrite. Scale is as much about team autonomy and release cycles as it is about throughput. Even if you are "just" decoupling the same Python code into different processes, you are solving a critical problem: you are de-risking your core and enabling your teams to move independently.
Framework M stays Zero-Cliff from Day 1 to Day 1000. We don't force you into a specific runtime or architectural shift to get the benefits of a distributed UI. Whether you are using it for a high-performance specialized engine or simply splitting your monolith for better manageability, the UI decomposition works exactly the same.
Summary
By focusing on a Modular Monolith with specialized backend engines where they make sense, we provide an "enterprise-scale" experience without the infrastructure complexity at the UI layer. You start with a single package, grow into a multi-repo suite, and scale to global CDN delivery—all without changing a single line of your React components.
It's not just about "pure engineering"—it's about giving you a pragmatic path to scale that matches your business reality.