search

openedx / wg-frontend

Open edX Frontend Working Group
4 stars 0 forks source link

Discovery: Bundle size is a blocker to builds #140

Closed jmakowski1123 closed 1 year ago

jmakowski1123 commented 2 years ago

Problem

Because each MFE is built completely separately, the LMS user has to download multiple bundles. Bundles may contain different versions of React, for example, causing the user to have to download duplicate data. Furthermore, the more MFEs are built, the less efficient this setup becomes.

Product/Platform Value

A smaller total download translates into a snappier experience for end users, particularly those with slower connection speeds.

Acceptance Criteria

Further discovery required, but there are a few theoretical options:

Related or in-progress work

Ghassan is undertaking discovery work which is being tracked in the MFE working group.

Contingencies

ghassanmas commented 1 year ago

@arbrandes Coming from https://github.com/openedx/frontend-app-account/pull/615

Here are my thoughts, work so far on this.

  1. chanign source-map (it get us to reduce bundle size but it deson't have effect on actual performace since, the huge file are related .map which don't get served by default to client)

  2. Tutor now comes enabled with encoded/zipped by default, this reduces the transfer size ~70%

  3. As for having common depencey between the MFEs I still in favour of this apporach since it will not only reduce bundle size per mfe but also reduce built time for MFEs[^1] . i.e we can get the best of both world.

    1. This apporach would vastly minize the image cahce size, which relate https://github.com/overhangio/2u-tutor-adoption/issues/85 by not having to install all commons npm depends X times where x is the number of MFE you use, rather you install one time, however here I am referring to production mode, I am not sure in development mode, good question is; Do people usually develop multiple MFEs in the same time?
    2. This approach would be challenge by the de-facto of how MFEs ecosystem is right now, qouting @davidjoy from openedx/frontend-app-account/pull/615

      It should not matter if MFEs have consistent versions of paragon - the code isn't shared anyway, I don't think it's meaningful to optimize for a consistent version. We shouldn't limit an MFEs version of a library because a different, independent MFE is at a particular version, that's not how the system was designed/intended to be used. ref

    3. There might be a workaround for 3.ii, the paying cost would be maintainability/complexity, i.e. you can build a system in such way it default to common version of depends, and then each MFE can flag if it needs spesfic version, then load that instead of the default one... There is POOC for this using module federation see point 6

  4. This issue also cross with #138 goals [^2],

  5. Regarding CDNs I also was doing something realted to it, I think this path is quite flexbile, but anyway such path might require archticure changes, consdier the following:

    1. Deploy all mfes in one subdomain i.e. apps.yourlms.com/mfe The de-facto tutor way of doing it
    2. Have an MFE for each subdomain i.e mfe.yourlms.com This de-facto edX/2U way of doing it
    3. Why not serve MFEs from the LMS/CMS I didn't see anyone doing it but in theory its possible
    4. I would argue though 5.i has the advantage of being easy to matain, while its cons is currently is that all the MFEs are coupled togather, while 5.ii is has a higher maintance cost with the benefit of being decoupled from the MFEs system. [^3]
    5. 5.i would be more straightforward to implement in terms of CDNs, you can in theory deploy the bundle MFEs on any site, then add a CNAME to point your subdomain to that automically generate link of the MFE bundle, this is quite common pattern, that I Cloudflare, Cloudfront/S3, Netlify support.
    6. We can stick 5.ii while serving assests from CDNs, this path would require building something like Webpack Plugin, where after the bundle asstes/files are omitted, we uplod them to CDNs service like S3/Cloudfront, Cloudflare. We would serve the document/HTML page from our server, but all the assets which HTML will request will be loaded from CDNs.
    7. I don't know about 5.iii I am mention bceause I am quite curious what can it bring to the table...

  6. Regarding module federation:

    1. It would complicate the maintaince of the project
    2. It would offer an interseting apporach the case of 5.i vs 5.ii bceause you would in theory serve jsut one APP and the that one apps can load any MFEs by a CDNs link

[^1]: We have a dedicated issue for bundle speed at #126 [^2]: For example I found that adding spesfic plugin would reduce CSS file by ~70% which is something good for #138 but might conflict with #126. [^3]: If you think in terms of how many people involve in DevOps between a typical tutor instance vs edX/2U, you would guess that both have chosen what work best for them.

arbrandes commented 1 year ago

I think we should move forward on this via the Modular MFE Domains OEP.