Topics

edx-platform’s front end architecture +5

• historical context on front end technologies (requireJS/webpack/etc.)

  • requireJS was the initial JS dependency tech, along with Backbone, jquery, underscore

  • later, we added webpack in order to support React

  • “react-render” is a function that folks can use to embed React in Django templates

• django vs mako vs ?? templates - when should you use one vs the other

  • Both of these are deprecated, in favor of React-based Micro-frontends

• Context:

  • team wants to track upsell links throughout the frontend (fire an event on-click)

• Q: preferred way to create + use a new JS file/module for use in the monolith’s front end

  • Recommendation:

    • New large-scale frontend development would be implemented in our latest frontend technology: React-based Micro-frontends - using our frontend-template “cookie-cutter”

    • For a minimal change, the team will probably not want to take on an entire re-write effort.

    • For middle-scale changes, the team needs to consider the trade-offs of addressing the tech-debt.

      • Option 1: Complete rewrite

      • Option 2: Middle-ground using “react-render” to embed new React code in the legacy code - to help with future rewrite

      • Option 3: Write in old tech

    • If the page is going to be rewritten within the next N months, don't need to invest as much time on otherwise “Clean Code” practices on the legacy frontend page.

      • With a team-backlog reminder (e.g., TODO statement with a Jira ticket) to remove that “hack” code in N months.

• Next steps:

  • Immediate collaboration with JJ to unblock her team

    • 1. Figure out the relevancy of a frontend page - TNL ticket - Marco Morales (Deactivated)

    • 2. Knowledge of the legacy code

  • Adding a Frontend ADR to edx-platform

travis vs jenkins +3

• what are they and what do we use them for?

• why is one used over another?

• sometimes front end code works locally in dev, but will fail the build. why & how are the linters/tests/compiling/etc different between development & the build?

  • for the most part, these should be similar.

  • there may be some dependency differences.

  • they are both running on ubuntu.

  • there may be a “bug” where we forgot to configure Travis to run in the same way as in Dev.

• Travis

  • is for CI. It runs tests on your PRs.

  • but we don’t have much control over it - parallelization is limited, for example (can fan out but can’t fan in again).

  • we get our own “container”, in which you can run whatever you want.

• Jenkins

  • is a more general job runner.

  • is used for CI for edx-platform.

  • we have much more control over this.

• GoCD

  • is currently used for CD (continuous deployment).

  • with kubernetes, we are planning to shift to ArgoCD for CD going forward.

    • ArgoCD is a much more lower-level tech - probably only accessible and used by SREs.

    • So we’ll probably invest in a higher-order tech on top of ArgoCD for developers to use.

• Q: Is there an intent to move away from Travis (like to Jenkins)?

  • There’s interest in moving away from Travis since it’s not as robust.

  • We tried CircleCI in the past - but that didn’t work out.

  • We’re considering GitHub Action as a possible replacement.

  • Not Jenkins: since CI is not it’s primary use-case and it may be a bit “wonky” to shoe-horn it to CI.

  • Travis and GitHub Actions are less maintenance costs - since we don’t need to host them.

symlinks between repos (e.g. MFEs to edx-platform) or within repos +4

• why are they used? how are they used?

why are there different files for the same pages between openedx & edx.org, esp. if the goal is to have openedx code be as close to edx.org code as possible? +4

• e.g. https://github.com/edx/edx-platform/blob/4b4d6c963d8d04a302c93932f13516dd122b331e/themes/edx.org/lms/templates/course_modes/_upgrade_button.html https://github.com/edx/edx-platform/blob/592b34b998245c446777fd334fd572af293d2236/lms/templates/course_modes/_upgrade_button.html

• There are 2 since we want to have a separate “theme” for edx.org that is different from the “vanilla” experience in the Open edX platform.

  • Out-of-the-box installation of the platform would display the vanilla experience - where the vanilla experience is a generic experience.

• Historical context

  • We introduced (and continue to support) “Comprehensive Theming”.

    • This feature allows Open edX instances to override entire templates to make their own customizations.

  • With MFEs, we plan to not support this wide breakable “interface” for theming. So “Comprehensive Theming” is essentially deprecated.

• Going forward

  • David Joy (Deactivated) will write an OEP on MFE frontend customization.