Arch Tea Time: 2020-06-25

Owned by Nimisha Asthagiri (Deactivated)
Last updated: Jun 25, 2020
3 min read

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