Achieving "Zero-Cliff" UI: How Framework M Solves Multi-Package Composition

Hello Framework M Community! 🚀

We just finalized ADR-0010, and it addresses one of the biggest headaches in modern enterprise software: How do we support a distributed plugin architecture without forcing a massive "infrastructure tax" on developers?

In most frameworks, you have to choose early: do you want a simple Monorepo (easy DX, hard to scale) or a Micro-frontend (MFE) architecture (great scale, nightmare DX).

With Framework M, we’re introducing Zero-Cliff UI Composition.

What is "Zero-Cliff"?

It means your code doesn't care how it's deployed. Whether you are running a pnpm workspace on your laptop (Level 1) or serving a globally distributed suite via CDN (Level 5), your React components and Python entry points remain exactly the same. You can climb from a prototype to an enterprise-grade deployment without hitting a structural "cliff" that forces a rewrite.

The Two-Mode Strategy

We’ve implemented two complementary modes that work together:

1. Build-Time (Monorepo/Bench): Our Vite plugin scans your workspace and creates a single optimized bundle. This is the "Indie" experience—fast, local, and simple.
2. Runtime Module Federation (Enterprise): This is the game-changer for pip-installed apps. In production environments where Node.js/pnpm aren't available, the host shell fetches pre-built remotes via a Discovery API (GET /api/v1/frontend/remotes).

Why this matters for you:

• No Node.js in Production: You can install wms-app or crm-app via PyPI, and the UI "just works" without needing a build step in your production container.
• Independent Release Cycles: Teams can update a single module’s UI without rebuilding or redeploying the entire Desk.
• The Python Source of Truth: We use Python entry points (framework_m.frontend) to drive UI discovery, keeping the backend and frontend perfectly in sync.

The "Modular Monolith" Advantage

While we support specialized headless engines like stock-keeper for high-throughput tasks, Business M (and any product built on Framework M) remains the unified hub. We aren't building a generic service aggregator; we are building a cohesive business suite that scales with you.

This post is a summary of the full technical deep-dive on the Framework M Blog.

What do you think? Does this approach to Module Federation solve the deployment hurdles you've faced with multi-package apps?

I'd love to hear your thoughts on the "Zero-Cliff" progression model.