Page Comparison

This document provides an overview of the Open edX Piral Shell Application, which is an implementation of the Piral Framework that addresses the requirements outlined in FC-0007. The complete prototype showcasing the use of piral-core to federate open edX MFEs is available at the following GitHub repository: https://github.com/hammerlabs-net/frontend-app-shell

...

The prototype comprises a simple Piral shell instance which includes two Piral plugins that extend the Piral API, and a mock pilet feed service as defined in the Piral Specification. The shell implements the lifecycle methods of the open edX frontend-platform library and exposes the endpoints of the library to Pilets (microfront ends - MFEs) loaded by the shell.

...

One of the goals of this prototype was to gauge the effort required to convert existing Open edX MFE to Pilets, and whether a conversion could happen in stages.

The required changes to MFE existing MFE’s are minimal (CAVEAT: this is evaluated in the context of converting the Account and Learning MFEs and the Header and Footer components. Other MFE’s may differ).

• index.jsx the main entry point requires refactoring. Previously MFE’s were responsible for initializing and responding to events from frontend-platform. In the new paradigm, the Shell manages interactions with the platform while MFE’s must implement the Pilet lifecycle method setup(piralApi). Instead of setting up routing and routes to components, Pilets register their components directly with the Shell via the registerPage(), and registerExtension() apis. This API The APIs can be extended to offer support for additional components (for example paragon components extensively used by existing MFE so that MFE’s can share a single definition of this important library, or alternative ones as the need arises).

• frontend-platform exported functions and objects now need to be wrapped and exposed from the Shell (where it is initialized) via the piral API. All uses of stateful methods previously imported from frontend-platform must be refactored in order to access the methods as exposed by the API. In the Learning MFE, we implement a simple helper object that is created during the setup() lifecycle method. (frontend-app-learning/src/data/api.js)

• redux store is now created centrally by the Shell. Instead of being responsible for their own storedstores, Pilets now simply wrap their rendered components in the DynamicModuleLoader HOC available in the redux-dynamic-modules library.

• The build process for MFE’s differs when bundling for Pilets. This prototype includes two new webpack configurations - one to bundle the shell itself and one to bundle MFEs. The second one in particular is very similar to existing Open edX development configurations but it removes the HTTP server as that is now handled by Piral. In addition, the make targets for these MFE’s have been deprecated in favor of the npm run build target which includes the Pilet packaging features to ensure compliance with the specification.

• Package depedencies: Piral’s ability to share dependencies will lead to substantial refactoring of existing package.json files. This prototype demonstrates how dependencies can be shared, but it does not make an attempt at addressing what should be shared. Piral documentation includes thoughts that should be discussion starters as we explore what should be shared centrally. An important consideration to highlight and explore is the size of the Pilet packages. Piral suggests MFE’s should remain under 1Mb, but the Learning MFE alone sits at 25.3Mb when bundled. A combination of tighter dependency management and/or refactoring of features into smaller Pilets during the conversion process can help allay some of the concern around package size.