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
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
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.
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.
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.
is a more general job runner.
is used for CI for edx-platform.
we have much more control over this.
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.
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.
@David Joy (Deactivated) will write an OEP on MFE frontend customization.