Purpose

The first iteration of the XBlock Rendering Summit will endeavor to frame the requirements and review potential solutions to the following questions:

Can we render XBlocks in MFEs in an architecturally sound manner, both performantly and securely? If one or the other, which one is more important?
- “securely” – Protects authors and learners in the scenario that a malicious actor gains the ability to edit course content. Would make it safe for us to distrust content authors, which is not currently the case. We still would need to trust xblock authors.
Can we do it in such a way that removes or reduces XBlock reliance on a frontend environment provided by edx-platform?
In general, how much do we want XBlocks to rely on an existing frontend enviroment? For instance, would it be desirable to have an XBlock view rely on React, or maybe even Paragon, being present?

Date, time, location

Feel free to request a direct invite from Adolfo Brandes if interested.

Date:07 Aug 2024, from 18:00 to 21:00 UTC (timezone converter)
Location: meet.google.com/bye-bigp-bhu

Agenda

Review of the problem space and requirements (30 minutes)
Solution presentations (15 minutes each)
Review of the solutions (1 hour)
1. Discuss how each solution meets requirements
2. Discuss relevant non-functional requirements, e.g., maintainability, flexibility, understandability.
3. Can we agree on a clear best choice?
Review and agree on next steps (30 minutes)

Requirements

We don’t trust content authors (from a security attack vector standpoint)
We should acknowledge that there are other places where XBlocks are rendered (not just MFEs)
Dependencies of XBlocks should be explicitly defined (there should be no magic)
Any solution should aim for unit page rendering performance to be comparable (or better!) to the current LMS or CMS implementations, particularly where a large number of XBlocks is concerned (think MIT courseware)
Any solution must be backward compatible with existing, unmodified course content - in particular Problem, Video, and HTML (as in, this content can be rendered perfomantly without modification). In case of adding new, more performant content (via new XBlocks or a new version of the XBlock API), it should be possible for modified content to co-exist with unmodified content
Keep both development and long-term maintenance simple

Approaches to discuss

Extracting XBlocks out of edx-platform

Kyle McCormick // https://github.com/openedx/edx-platform/issues/34827

This approach only solves part of the problem but I want to discuss it because it’s already in progress.

Basically, the Aximprovements team and I are trying to extract the leaf xblocks which are built into edx-platform (word_cloud, problem, html, etc.) into a separate repo, where they’d behave like standard xblocks rather than the kinda-xblocks-kinda-hardcoded state that they are in now.

This is relevant to XBlocks rendering because we plan to:

convert all the builtin block Sass into CSS and extract it. This will remove the need to compile XBlock Sass. This is in progress now.
extract XBlock JS into the separate repo and precompile it. This will remove the need to run webpack on XBlock JS. This in the feasibility/discovery stage.

The end result will be that XBlock assets will still need to be collected & served*, but they will not need to be built in edx-platform. Once the MFE conversion process is otherwise complete, this will allow us to majorly simplify edx-platform.

*it is worth noting that we will always need to collect & serve assets from edx-platform if we want Django Admin to work.

Performance improvements to current iframe approach

Dave Ormsbee (Axim) and others believe it might be possible to get sufficient performance improvements out of the current iframe approach by reducing (perhaps conditionally) the number of dependencies that get loaded in each frame.

Iframe Rendering and Studio UI Overlay (for Studio Unit Page)

This isn’t a general fix, but something aimed specifically for making the Unit page render in an acceptable manner. The idea would be to render the Unit’s XBlocks in a single iframe using the preview URL for the /xblock endpoint (or its v2 equivalent for better sandboxing), and then have that Unit render placeholder divs between the Unit’s items. The XBlock rendering in the iframe would then send a postMessage() giving the locations of those spacer divs alongside the resizing logic that’s already emitted for the Learning MFE. The MFE listens for that postMessage, calculates the absolute position of those spacer divs based on the local coordinates and the iframe coordinates, and shifts around its component toolbars to overlay on top.

We'd have to modify the unit rendering further to have a mode where it doesn't render sub-units (since that would be handled differently in Studio). We'd also probably want to collapse/hide the whole iframe when doing reordering, because dynamically sliding the pieces around would be problematic to implement.

XBlocks 2.0

Braden MacDonald proposes architectural changes to XBlocks that would help solve the problem, as defined in the following document:

https://docs.google.com/document/d/1xelb7iGvWRtT71F2c_dBkQEB47Cj0etT5VGgbVdAPKY

An MFE for each XBlock type

This is not a solution to the rendering performance problem, but Adolfo Brandes notes (but does not necessarily defend) that an MFE has already been developed specifically for the Open Response Assessment block:

https://github.com/openedx/frontend-app-ora

This is one way to go about modernizing how to develop XBlock UI. Should we support it for other blocks?

Existing information

Meeting Summary

🎥Recording

Attendees

Adolfo Brandes, Braden MacDonald, Brian Smith, Dave Ormsbee, David Joy, Ed Zarecor, Emad Ehsanrad, Glib Glugovskiy, Jenna Makowski, Jeremy Ristau, Kristin Aoki, Kyle McCormick, Muhammad Qasim Gulzar, Ronak Pansuriya, Sandro Costa, Zameel Hassan

Key Points and Proposals

Problem Statement

The summit was called to address issues with XBlock rendering, particularly focusing on performance problems encountered when rendering unit pages with many XBlocks. This has led to a poor user experience in Studio, prompting the need for a better solution.

“Single Iframe Solution” Proposal by Dave Ormsbee (Axim)

Instead of rendering each XBlock in its own iframe, use a single iframe for all XBlocks in a Unit using the /xblock endpoint of the preview server.
- Have that unit rendering include empty divs as placeholders.
- Have the Authoring MFE overlay the per-Component toolbars on top of those placeholders.
- The iframe contents use postMessage() to communicate the locations where those overlays are needed, in a way that is similar to what happens with iframe re-sizing on the Learning MFE.

This is a more tactical proposal to move Studio to the new Unit page, and does not conflict with other, larger scale, long-term modernization efforts.
Advantages:
- Improves performance by reducing the number of iframes and significantly reducing the number of JS assets that need to be processed.
- Does not require major rewrites of XBlock or runtime functionality–seems feasible to do for the Sumac timeframe.
- In the longer term, may provide us with better fidelity previews that are inline with the Unit itself (and give us a way to move off of needing a separate preview domain).
- In the longer term, may give us an acceptable pattern for frontend plugins to decorate and interact with XBlock content (e.g. “submission history”, “staff debug”).
Challenges:
- Not a common pattern, which may lead to confusion.
- Re-ordering components in a unit will likely require some special case handling (e.g. hiding the iframe and collapsing the component toolbars together), because we can’t reorder within the iframe document.

Proposal by Braden MacDonald

Modernizing XBlock Rendering: Move towards using JSON to return data from XBlocks, and have the front-end render this data using modern JavaScript frameworks like React or Preact.
Web Components: Use web components to encapsulate XBlock functionality, allowing for better isolation and more flexible, maintainable code.
Advantages: This approach modernizes the XBlock architecture, provides a more responsive and faster-loading user experience, and simplifies the development process for new XBlocks.
Challenges: Requires rewriting the front-end code for existing XBlocks, which is a significant effort.

Immediate Actions and Concerns

Short-term Solution: Consensus leaned towards adopting Dave's single iframe proposal for the immediate need to meet the Sumac deadline.
Long-term Solution: Braden's proposal was seen as highly beneficial for the long-term evolution of the platform, despite being infeasible for the immediate deadline.

Next Steps

Estimation and Planning: There is a need to estimate the effort required to implement Dave's proposal and integrate it into the current project timeline.
Coordination: This task will be coordinated under the libraries project, with discussions to be held in relevant working groups and internal meetings.
Continued Discussion: Further discussions will be held to explore the feasibility of Braden's long-term proposal and how to integrate it into the platform's future roadmap.

Conclusion

The summit concluded with a plan to pursue the single iframe solution for the short term to meet pressing deadlines while acknowledging the need to revisit and potentially adopt Braden's proposal for a more sustainable and modern architecture in the future.

XBlock Rendering Summit, Part 1 (2024-08-07)