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.

...

By leveraging the Kras server proxying library, which is integrated into Piral, the shell implements an MFE Feed Service that demonstrates how different configurations of pilets can be loaded into the shell. A simple change in the "Pilet Feed" can load an entirely different set of pilets into the shell, allowing the same Shell to host various Open edX applications such as Studio or LMS, or utilize different to offer alternative brand UX (edX vs open edX), or even to provide alternative MFEs suitable for specialized deployments. Moving this configuration to an external service, as recommended by Piral, would provide a highly configurable and flexible solution for Open edX deployments at run time.

This Piral instance leverages the Piral plugin mechanism to deliver a custom plugin that showcases the ability to address UX and UI consistency issues across MFEs while significantly improving the capability to deliver alternative layouts and designs to Open edX audiences.

...

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.