Carlos Cifuentes
Glossary

Remote (micro-frontend remote)

A remote is a separately built and deployed application that exposes modules, such as routes or components, for a host to load at runtime.

A remote is one of the applications that a host loads at runtime. It is built and deployed on its own, usually by the team that owns that business area. It exposes one or more entry points, typically a set of routes or a root component, and the host mounts them inside its layout.

A remote should also be able to run by itself. A standalone mode with its own small index.html lets the team develop and test without starting the whole platform.

Example

The invoices team owns a remote named invoices. Its federation configuration exposes a routes file:

exposes: {
  './routes': './src/app/invoices.routes.ts',
}

The team deploys it to https://cdn.example.com/invoices/. The host maps the /invoices path to that exposed module. When the team ships a fix, it deploys its remote only. The host and the other remotes are untouched.

Common misunderstanding

Independent deployment does not mean a remote has no contract. A remote depends on the host for shared library versions, for the session, for design tokens and for the shape of the URL space. If a remote moves to a new framework major version ahead of the host, or imports directly from another remote, the system breaks at runtime, where no compiler can warn you.

Treat the exposed modules, the shared versions and any events as a public API. Version them and cover them with contract tests in the pipeline. More detail is on the micro-frontends page.

Why it matters. The remote is the unit a team owns and releases. In a migration, each migrated area can become a remote that replaces the matching part of the legacy application.

Related terms

Planning a migration or a micro-frontend platform?

In a 20-minute call you describe your situation and I tell you how I'd approach it. If it isn't worth doing yet, I'll say so.

Message me on LinkedIn