Micro-Frontends

Terminology

• master: the host application, the entry point exposed to users, responsible for loading services.
• service: the sub-application, meant to be nested inside the master and run together, while also supporting autonomy.

Concrete Problems in Micro-Frontend Practice

Routing

Since many services may be integrated, services need to be lazy-loaded / lazy-initialized.

Should the route table live in master or in service?

If it lives in master, the service cannot start independently without the master, unless you duplicate a whole route table.

If it lives in service, then in master—well, master needs to fetch the service's route table and register it globally.

Considering that services need autonomy, the route table should live in the service and be loaded when master initializes.

When master loads a service's route table, should a route prefix be added?

If no prefix is added, refreshing directly on a service page leads to the situation where master finishes initializing before the service does.

At that point, because the routes in the service have not been initialized yet, a 404 occurs.

If a prefix is added, note that the business may perform authentication based on the URL; if the URL is modified, the prefix must be uniformly stripped in the authentication step to avoid match failures.

Drawbacks of iframe

• URL not synchronized:
  • Once the browser refreshes, the iframe URL state is lost.
  • The forward and back buttons cannot be used.
• UI not synchronized: The DOM cannot be shared, making interactions like global modals, masks, and centering hard to implement.
• Context fully isolated:
  • Memory variables are not shared, so communication, data synchronization, and similar needs require extra handling.
  • Cookies are not shared, so the main site's cookies need to be passed through to each sub-application for authentication.
• Slow loading: Every sub-application needs to re-initialize and reload resources each time, which is very slow.