Frontend Glossary

Frontend Glossary#

High Level Concepts#

App#

A self-contained part of the Open edX Frontend that is composed into a Site. An app represents a well-bounded area of the UI - such as courseware, the login page, or account settings - and typically owns one or more routes. It declares its own routes, Slots, providers, configuration, and the Widgets, services, or scripts it contributes.

Apps are composed into a Site at build time by being imported into its Site Config. In the historical Micro-frontend Architecture, the frontend-app-* repositories were independently deployed applications (“MFEs”); in the Composable Architecture they become App Repositories, each providing one or more apps. Components previously built as frontend-plugin-framework plugins are likewise converted into apps, each contributing its UI to a Slot as a Widget.

App Repository#

A repository (frontend-app-*) that provides one or more apps in the Composable Architecture. Most App Repositories provide a single app, but some provide several related apps - for example, frontend-app-learning might provide the courseware, course outline, progress, and dates apps, which share code and dependencies specific to their domain. This stands in contrast to how the frontend-app-* repositories were used in the Micro-frontend Architecture, where each was a single deployable application.

Micro-frontend#

Micro-frontend is an industry standard term for small, composable, independently deployed pieces of a frontend. It has a specific and narrower meaning in Open edX’s frontend. Open edX’s decoupled frontend architecture has been called the “micro-frontend architecture” since 2018 or so, and the frontend-app-* repositories, specifically, are referred to as “micro-frontends” or “MFEs” for short. Some might argue it’s a misnomer, as many of our MFEs are quite large. Regardless, MFEs in Open edX refer to our independently deployed, siloed frontends which do not share dependencies, and which may contain one or more distinct parts of the overall frontend.

The Composable Architecture supersedes this approach: the frontend-app-* repositories become App Repositories rather than standalone applications.

Micro-frontend Architecture#

This is the name for the Open edX frontend architecture based on frontend-platform, frontend-build, and independent frontend-app-* repositories that represent micro-frontends. It has been superseded by the Composable Architecture.

Open edX Frontend#

The complete set of interfaces shown to a user of an Open edX instance. It consists of one or more independently deployed Sites.

Shared Dependencies#

The capability to share a frontend’s dependencies (such as React or Open edX’s Paragon) between the apps composed into a Site. Because those apps are composed into a single build, each shared dependency is bundled only once, which has a significant impact on overall download size for frontend clients.

Shell#

The top-level frontend, provided by the frontend-base library, that composes a Site. The shell initializes the application, loads the shared dependencies, renders the layout (including the header and footer), loads the brand, and composes the apps declared in the Site Config.

Composable Architecture#

The name for the Open edX frontend architecture based on frontend-base, the Shell, apps, and Sites. It supersedes the Micro-frontend Architecture. Frontends are composed into a Site at build time rather than deployed as independent single-page applications.

Site#

An independently deployed portion of the Open edX Frontend that contains an instance of the Shell. In practice, a Site renders the header and footer and composes one or more apps into a single bundle, defined by its Site Config. A frontend may consist of one Site or several independent Sites, depending on an operator’s needs. Navigating between Sites involves a full-page refresh and downloading a new set of dependencies.

A Site is also where an operator checks in the configuration and customizations for a deployable part of their frontend. Operators typically maintain a Site as their own repository (for example, based on frontend-template-site).

Site Config#

A TypeScript file (site.config.tsx) which represents the configuration of a Site. It imports the apps the Site composes, configures them, and declares the operator’s customizations. It must adhere to the SiteConfig TypeScript interface, and is runtime code.

Slot#

A designated place in the component hierarchy that will accept Widgets. Slots have documented layout expectations, configuration requirements, and contextual data that they share with the widgets composed into them.

Widget#

A component composed into a Slot. Widgets are how apps and operators extend or override parts of a page - for example, adding a new tab to the course home, or replacing the header - without modifying the app that owns the slot. An app contributes widgets to the Slots of the Shell or of other apps.

Migration#

External Route#

A route in a Site that navigates to an external URL rather than composing an App. The destination may be another Site, or it may just be some other webpage, such as a support portal. External Routes are an important architectural option which allows us to do partial or gradual updates of the Open edX Frontend by dividing it into pieces. If a frontend needs to migrate through breaking changes in its dependencies, like React or React Router, we can split it into two Sites and use External Routes to move between them while migrating apps from one to the other as they adopt the change. It also allows some frontends to remain as independently deployed, legacy MFEs during migration.

Change History#

2026-07-13#

  • Rewritten to match the frontend-base reference implementation: the composable unit is an App (not a “module”), operators compose apps into a Site (not a “project”), and composition happens at build time. Removed terminology for the dropped runtime module federation approach (Module, Module Federation, Federated Module, Federated Plugin, Remote, Remote Discovery, Guest, Host, Runtime Module Loading) and the Project/Module Project/Site Project concepts. Renamed “Module Architecture” to Composable Architecture.

  • Renamed “Plugin Slot” to Slot. Replaced the “Plugin” term (and the “Imported Plugin” / “IFrame Plugin” subtypes) with Widget, the component composed into a Slot. Existing frontend-plugin-framework plugins are converted to apps, just as MFEs are; the build-time vs iframe loading distinction is now described in the Widget definition.

  • Renamed “Linked Site” to External Route to match frontend-base, reframing it as a route that points to an external URL rather than a kind of site.