1 of 25

State of Open edX�Community and�Architecture Engineering

Nimisha Asthagiri | Jeremy Bowman | Sarina Canelake

Open edX Managers, edX

Recording and Slides will be available.

2 of 25

Agenda

Community Vision
Architecture Vision
Technical Roadmap

Recording and Slides will be available.

2

3 of 25

Community Vision

4 of 25

Open edX Theme Purpose

To empower the community to build the best online learning platform

4

Empower - to enable; to make someone stronger & more confident

Best -

The Open edX platform doesn’t have feature gaps, the broad community of users and contributors ensures that
The community is an engine for innovation and experimentation; when moonshots land, they’re adopted
The platform of choice - External adoption has grown 10 times, there are more than 10K sites and 300K courses outside of edX

Agricultural course - figure out how to work this in

“Hey Sarina, it’s great to see what our vision is for the future. What about today?”

“How are we currently empowering the community?” - one great example is our working groups!

BTR wg - empowered to lead the release of Lilac!
Marketing wg - design our conference! Also built the extensions directory on open.edx.org - https://open.edx.org/the-platform/extensions-directory/

5 of 25

Scaling Platform Development Efforts

5

6 of 25

Transparency in Development

6

7 of 25

7

8 of 25

Advancing the Platform, Together

8

9 of 25

Architecture Vision

10 of 25

Scaling Platform Development Efforts

11 of 25

Scaling Platform Development Efforts

12 of 25

Scaling Platform Development Efforts

1. Boundaries

2. Extensions

3. Events

Intentionality

13 of 25

1. Boundaries

First step.. (as with many things in life) setting boundaries.

Depicted with a box.

Each box has its own set of clear responsibilities. With it being well documented in its own README.

For example, in our very own platform, we have yet to make a clear separation between the code for the learner dashboard and the code for user access control.

They are currently in the same box and need to be separated.

Once we have such boundaries in place, contributors will then know where things are located and where to make changes.

What we have begun to do in our platform, is separate our frontend from our backend.

Frontend code runs in the users browser.

Backend code runs on our servers, hosted in the cloud.

Sarina: I feel something is missing? Are you forgetting something?

Thank you Sarina.

Yes, of course. We can’t forget our 2 million LOC beloved pet - our monolith.

Our monolith - doesn’t really look like this - nice and simple large box. It’s very spaghetti-ish inside.

So we cannot easily create physical boundaries inside the monolith.

But we can draw logical boundaries inside.

We can create clear separation of concerns. And document them!

14 of 25

Frontend Plugin Framework

with Javascript APIs & Hooks

Backend Plugin Framework

with Python APIs & Hooks

2. Extensions

15 of 25

3. Events

A. Backend� Apps

B. Micro Services

C. Micro Frontends

D. Frontend� Apps

Thirdly, an event driven architecture is a an excellent design pattern to inform extensions or other services when something happens - in a very de-coupled way.

The notifications can be in real-time. So whoever’s listening, can know almost immediately that an event occurred.

For example, once a learner completed their exam, your widget on their learner dashboard can stop pestering them to study. And this can happen without the core platform knowing anything about your widget. Your widget simply needs to listen for events that it’s interested in.

Even other extended services in the system will want to react accordingly, when something happens.

For example, when a learner completes a course in the LMS, our separate credentials service will want to make sure a certificate or badge is properly generated.

Jeremy: “So that covers notifying backend services of events, but you said we’ll be doing a lot more frontend services also. What are we doing for our frontend services?”

16 of 25

Intentionality

Finally, we want to ensure we continue an intentional outlook on our platform architecture

So that we do not regress

And that we continue to support the thousand and growing number of engineers.

Here’s a snippet from our Architecture Manifesto. The manifesto reminds us of our basic architecture principles, including the 3 we mentioned just now.

In addition, here are a few other pointers from the manifesto that remind us how to remain deliberate with our efforts.

For example

Work to simplify beats slippery complexity.

Let’s continue to refactor - as needed.

Code does grow in complexity unless we simplify and refactor as we go.

Code does get stale. Code does need to be removed when it’s no longer needed.

Another one I’d like to call out.

Decision Records

Are a means to stop and do timeboxed design and write down tradeoffs

before we jump into coding.

We have Arch Decision Records and Open edX Proposals as tools already in our platform for doing so.

So continue to do those along the way, and we’ll ensure that our platform continues to grow in a scalable and intentional way that we need it to be.

17 of 25

Scaling Platform Development Efforts

1. Boundaries

2. Extensions

3. Events

Intentionality

18 of 25

Architecture Vision - More Info

Architecture Manifesto wiki (link)�
Architecture Study Group Workshops (link)�
Architecture Onboarding Presentation (link)

19 of 25

Technical Roadmap

20 of 25

Architecture Roadmap Excerpt*

20

* See https://openedx.atlassian.net/wiki/spaces/AC/pages/1812037671/FY21+Architecture+User+Story+Roadmap

21 of 25

Community Vision - Supporting Efforts

Transparency in development

Advancing the platform, together

Python 3.8 upgrade (EduNext, many others)
Elasticsearch upgrade (with Raccoon Gang)
Common Cartridge support (with OpenCraft)
xAPI/Caliper support (Edly)
Feature toggles documentation (Overhang.io, many others)
Django 3.2 upgrade preparation (lots of opportunities to contribute)

21

22 of 25

Architecture Vision - Supporting Efforts

Boundaries

Extensions

Events

Intentionality

ADRs for OEPs (examples: OEP-5 and OEP-37)
DEPR (code deprecation process)

22

23 of 25

Thank you!

Any questions?

Join us in Q&A

Connect in Slack (#architecture)

24 of 25

25 of 25

Platform Innovation

Community Innovation

Business Innovation