ABCDEFGHIJKLMNOPQRSTUVWXYZAA
1
nameringquadrantisNewAuthor(s)Reviewer(s)Review complete? Y/Ndescription
2
Temp AdoptedAdoptedTechniquesDavid JoyDavid JoyY
3
Temp AcceptedAcceptedFrontendDavid JoyDavid JoyY
4
Temp ProvisionalProvisionalTechnologiesDavid JoyDavid JoyY
5
Temp HoldHoldOpen edXDavid JoyDavid JoyY
6
ADRsAdoptedTechniquesNimishaSarinaYADRs are local lightweight documents of technical decisions co-located with its corresponding code. They are much easier to maintain than traditional design documents since they are a running log of decisions without the need to update old decisions.</br></br>They allow developers to understand the rationale behind the code and the archeological path to its current state. These records prove to be an <a href="https://www.thoughtworks.com/radar/techniques/lightweight-architecture-decision-records">invaluable technique</a> for engineering teams to onboard new members, to understand discovered historical traces, to refer back to past decisions, and to support external oversight. See <a href="https://github.com/edx/open-edx-proposals/pull/74/">OEP-19: Developer Docs</a> for more information.</br></br>See 'Blip: OEPs' as an alternative process for documenting technical decisions that have system-wide impact.
7
Ball of MudHoldTechniquesDavid JoySarinaYWe often refer to the edx-platform monolithic repository as a "ball of mud", because it lacks clear boundaries and extension points. This is not a pattern we want to continue, and much of our work is focused on cleaning up the "ball of mud" via the techniques in the 'Blip: B.E.E.S' blip.
8
B.E.E.S.AdoptedTechniquesNimishaSarinaYWhile the <a href="https://openedx.atlassian.net/wiki/spaces/AC/pages/1074397222/Architecture+Manifesto+WIP">Architecture Manifesto</a> provides long-term principles for our technical architecture, B.E.E.S. is a mnemonic acronym for the 4-pillar architecture strategy that will lead us to our vision: an extensible distibuted system that supports long-term innovative growth.
</br></br><ol>
<li><b>Boundaries</b> - see 'Blip: Boundaries (domain-driven)'</li>
<li><b>Extensions</b> - see 'Blip: Extensible Cores'</li>
<li><b>Events</b> - see 'Blip: Event-driven Architecture'</li>
<li><b>Standards</b> - see 'Blip: Standards-based Development'</li>
</ol>
</br>See the <a href="https://docs.google.com/presentation/d/1Tm-Ha1rc8Ifj8UDMhhUiQ8Rk55zRDTZJkDcoq8lUsHc/edit">Arch B.E.E.S. slides</a>, including speaker notes, for more information.
</br></br>We are moving forward on all 4 simultaneously through active efforts on our <a href="https://openedx.atlassian.net/wiki/spaces/AC/pages/1812037671/FY21+Architecture+User+Story+Roadmap">architecture roadmap</a>.
9
Boundaries (domain driven)AdoptedTechniquesNimishaSarinaYDefining <b>boundaries</b> is needed to achieve modularity and a decoupled system. Defined boundaries allow us to know the intended responsibilities of components and how they are intended to evolve over time. A component can be a single Python module, a Django app, a Frontend folder, a Plugin, an entire microservice or microfrontend.
</br></br>
Not all boundaries are created equal. There are tradeoffs. Business-minded long-term implications for cohesion and coupling need to be considered. See the slides and video from the <a href="https://openedx.atlassian.net/wiki/spaces/AC/pages/1287684148/Arch+Study+Group">2020-09-08 Arch Study workshop on Boundaries</a> for a deeper dive and exercises on this topic.
</br></br>
The <a href="https://openedx.atlassian.net/wiki/spaces/AC/pages/1074397222/Architecture+Manifesto+WIP#Clear-Bounded-Contexts">Clear Bounded Contexts section of the Architecture Manifesto</a> provides additional links for what to consider when defining business-minded boundaries, including Domain-driven Design.
</br></br>
Finally, take a look at 'Blip: READMEs' for a technique to document a component's Single Responsibility.
10
Code coverageAdoptedTechniquesNedSarinaYCode coverage is used during testing to assess what portions of the code are being exercised by the tests. It provides information to code authors about gaps in testing, and helps to provide assurance about the correct behavior of the code.
We don't have a specific target we are trying to hit. In some repos, we have checks that a pull request has not decreased the total coverage percentage.
11
Consumer-based API contract testingProvisionalTechniquesNimishaSarinaY<a href="https://martinfowler.com/articles/consumerDrivenContracts.html">Consumer-driven contracts</a> are an essential part of a mature microservice testing portfolio, enabling independent service deployments. When two independently developed services are collaborating, changes to the supplier’s API can cause failures for its consumers. Consuming services usually cannot test against live suppliers since such tests are slow and brittle. Consumer teams can protect themselves from these failures by providing their own tests to the supplier, who can then run all their consumers’ contract tests to determine if their changes are likely to cause problems.
12
Conventional CommitsAdoptedTechniquesNedSarinaY<a href="https://www.conventionalcommits.org/en/v1.0.0/">Conventional Commits</a> is a
set of guidelines for writing git commit messages. Our standard for using conventional commits
is <a href="https://open-edx-proposals.readthedocs.io/en/latest/oep-0051-bp-conventional-commits.html">OEP-51, Conventional Commits</a>.
Conventional commits guide the author to indicate the broad category of change, and its implications.
Using conventional commits helps readers and adopters of the code to understand how it is changing.
Conventional commits are not currently required, but are <i>strongly</i> encouraged.
13
CSS-in-JSHoldTechniquesDavid JoySarinaYCSS-in-JS is a technique - <strong>not currently used by Open edX</strong> - in which styles are embedded into JavaScript-based UI components, rather than being coded into a CSS file. It is an attractive option in that it promotes modularity by co-locating styling information with the component that needs it, similar to how JSX started co-locating markup with the JavaScript that manipulates it. The decision to use CSS-in-JS techniques/libraries in the future is complicated by the need to keep our system themeable, and also our hesitancy to replace our Bootstrap-based styling with a completely different system. Such a change could not possibly happen all at once, in which case we would exist with two separate styling systems for some period of time, which would be pretty problematic.
14
DEPRAdoptedTechniquesNimishaSarinaY<i>Remove dead code wherever possible. It gets in the way and slows you down.</i> </br></br> <a href="https://open-edx-proposals.readthedocs.io/en/latest/oep-0021-proc-deprecation.html">OEP-0021: Deprecation and Removal</a> defines a clear and agreed upon process for removing legacy code, which we strongly encourage everyone to follow and put into regular practice as part of the normal development lifecyle.
15
Docs right in the repoAdoptedTechniquesFeanilSarinaYWhenver possible documentation should be localized to the thing it is describing. This helps both with discovery of the documentation by readers but also helps ease the burden of documentation maintenance since writers can update the documentation alongside the code that it describes. See <a href="https://open-edx-proposals.readthedocs.io/en/latest/oep-0019-bp-developer-documentation.html">OEP-19</a> for more details.
16
Experimenting and A/B testing with django waffle experiment flagProvisionalTechniquesGabe MulleySarinaYExperiments are intentionally developed very quickly with fewer quality controls since it as assumed that most will be unsuccessful and will later be removed. It is common that some courses will want to "opt-out" of particular experiments. The <a href="https://openedx.atlassian.net/wiki/spaces/AC/pages/1250623700/Bucketing+users+for+an+experiment">ExperimentWaffleFlag</a> provides a fast kill-switch for experiments as well as standardizing a process for excluding courses from experiments that would otherwise have been included. These tools enable re-use of experiment-related analytical tools since they standardize the data emitted by the experiment. Lastly, these tools make it simple to keep track of all experiments that have not yet been rolled out or removed by simply searching for usages of this type of feature flag.
17
Extensible coresAdoptedTechniquesFeanilSarinaYTo allow Open edX to solve different problems for different people in the community, having the core software be extensible is essential. Because we have adopted a micro services architecture (See 'Blip:Micro-services'), there is no single core but rather a series of core systems that should each provide extension points to allow for experimentation and innovation at a faster development speed than if all features had to be directly merged into the core systems.
18
Lint / Auto reformat on commitProvisionalTechniquesJeremy BowmanSarinaYUsing a local commit hook to run a tool (such as black) to automatically reformat source code before the commit completes, which saves time vs having a CI check that tells a developer that there's a problem with their formatting and they need to go run the tool themselves and make a new commit. Some individual Open edX developers may be doing this, but it hasn't yet been adopted as a standard practice.
19
Micro-frontendsAdoptedTechniquesDavid JoySarinaYMicro-frontends (MFEs) are an approach to developing frontend applications where the site is broken up into domain-specific modules which are then independently deployed and maintained in separate repositories. This helps establish strong boundaries around these domains and ensures they remain loosely coupled. The approach is the frontend version of a micro-service architecture. In the Open edX platform, micro-frontends are purely frontend and contain no backend code. MFEs communicate with backend services via RESTful APIs (generally), and share some foundational libraries like frontend-build, frontend-platform, and paragon. A downside of this approach is that each MFE bundles its own third-party dependencies, so there is some code duplication and redundant assets as a user navigates around the site from MFE to MFE. We've found the micro-frontend approach to have a very positive effect on developer velocity and our ability to continuously deploy our frontends. We are in the process of replatforming all "legacy" frontends to be micro-frontends.
20
Micro-servicesAdoptedTechniquesJeremy BowmanSarinaYUsing a collection of small services, each dedicated to a specific functionality domain, rather than one monolithic service for an entire site. Open edX started as a monolithic service but has started implementing more and more functionality in new micro-services to accelerate development and improve maintainability as the platform grows.
21
Module federationProvisionalTechniquesDavid JoysarinayModule federation is a technique allowing us to share JavaScript modules across independently deployed micro-frontends. While we are not using it today, we believe it can help us firm up our domain boundaries, allow teams to work more independently, and reduce bundle sizes by sharing common modules used by multiple MFEs. It comes with some complexity around versioning of shared dependencies, however, which has prevented us from moving forward with adoption. Because it has no ability to establish a security sandbox around code loaded from outside our trust domain, it has limited utility for extensibility. Supporting module federation in MFEs is not currently scheduled on our roadmap.
22
OEPsAdoptedTechniquesNimishasarinaYOEPs (Open edX Proposals) are a collection of system-wide technology decisions accepted by the Open edX community. They come in the form of best practices, architecture designs, or processes. Inspired by <a href="https://www.python.org/dev/peps/pep-0001/">Python Enhancement Proposals (PEPs)</a>, each OEP provides its use cases and rationales. OEPs are described in <a href="https://open-edx-proposals.readthedocs.io/en/latest/oep-0001.html">OEP-1</a> and published in the <a href="https://open-edx-proposals.readthedocs.io/en/latest/index.html">OEP Index on Read the Docs</a>.</br></br>See 'Blip: ADRs' as an alternative to OEPs for a lighter weight process to document localized technical decisions.
23
PR deploy previewsProvisionalTechniquesAdam StankiewiczsarinayPR deploy previews are a way of improving our CI/CD pipeline by allowing us to share and see our code running in an environment prior to merge into main. We primarily use this in Blip: Paragon today, but its a technique we'd like to expand to micro-frontends in general. On each commit of a component library or micro-frontend, we would build and deploy a preview of the changes made in the commit / PR, and keep this deploy preview up-to-date on successive commits within the same PR.
24
Server side templatesHoldTechniquesDavid JoySarinayServer-side templates are a technique used to render HTML on the server and then serve it to the client as part of the initial page load. In our ecosystem, it is most commonly done via Django templates in our "legacy" frontend systems. It is not done in any micro-frontends, in favor of using React and client-side rendering to generate as much of the page as possible.

We're moving away from using server side templates as part of the micro-frontend replatforming. They tightly couple frontend rendering to backend code and DB queries, and when not used mindfully, blur API boundaries of both the frontend and backend, reducing the overall extensibility of the platform.
25
Synchronous signal handling (Django signals)AdoptedTechniquesJeremy BowmanSarinaYAn in-process publish/subscribe framework built into Django. Basically a lighteight eventing system useful when the event handlers are local and finish quickly. Open edX uses these extensively in many of its services and packages.
26
Test driven developmentProvisionalTechniquesJeremy BowmanSarinaYWriting test cases for changes in the software's behavior before writing the code that implements those changes. It can help clarify thinking about how the software should work before getting lost in implementation details. We rarely do exactly this for Open edX, but we usually require relevant tests to be present before changes can be merged.
27
Type annotationsProvisionalTechniquesJeremy BowmanSarinaYOptional metadata for the types of Python function arguments and return values, which can be used to gain many of the benefits of static type checking. We're currently only using this in 3 Open edX repositories, but would like to start using it more extensively. Here is the relevant <a href="https://github.com/search?q=mypy+repo%3Aedx%2Fblockstore+repo%3Aedx%2Fedx-platform+repo%3Aedx%2Fopenedx-webhooks&type=Code&ref=advsearch&l=&l=">mypy configuration and usage</a>.
28
axiosAdoptedFrontendAdam StankiewiczLong LinyPromise-based HTTP client to make asynchronous HTTP requests to REST endpoints to perform CRUD operations. This library is used as the basis for the 'auth' module in Blip: frontend-platform and handles all our API communication between micro-frontends and our backend services. We use its concept of "interceptors" to add request and response handling. Axios is an integral part of our micro-frontend platform today, and we plan to continue to use it.
29
babelAdoptedFrontendBen WarzeskisarinaYJavascript Transpilation service that allows use of modern JS syntax and tools in older browsers by transpiling advanced ES6 into browser-friendly ECMAScript. We use this as part of our build process for all modern JS systems.
30
backboneHoldFrontendBen WarzeskisarinayJS UI-creation library present in legacy code systems. It provides a powerful MVC framework, with less focus on small composable code.
Our legacy JS is written in this architecture, but we are moving away from it as a company, towards React as a framework
31
BootstrapAdoptedFrontendBen WarzeskisarinayPowerful industry-standard JS and CSS styling tools, providing sass variables and mixins, a responsive grid system, extensive prebuilt components, and powerful JS plugins.
This is the underpinning scaffolding and styling tool library used for much of our Open edX JS/CSS styling.
32
cypressProvisionalFrontendJeff WittSarinay<a href="https://www.cypress.io/how-it-works/">Cypress</a> is an end-to-end testing package with multi-browser support. We have wanted to make use of Cypress for functional testing of our micro-frontends for some time as a means to round out our test suites, which are primarily Blip: Jest based today. See also <a href="Playwright.dev">Playwright.dev</a> and <a href="https://github.com/puppeteer/puppeteer">Puppeteer</a> as alternatives.
33
enzymeAcceptedFrontendBen WarzeskisarinayReact component testing library with a particular focus on snapshots and class components.
We use this in some MFEs for React unit testing. Our recommendation is to move away from using enzyme for component testing, and suggest using Blip: testing-library instead. Enzyme has a more complex set of testing primitives than testing-library, (subjectively) making it a bit harder to reason with. Blip: testing-library has a simpler API, promotes standard ways of querying the DOM, and helps us keep our code accessible by encouraging a11y/ARIA-based querying for writing expectations/assertions.
34
ES6AdoptedFrontendBen WarzeskisarinayECMAScript 6 is a version of the ECMAScript standard, providing many advanced syntax and capabilities to modern JS development, including the const/let keywords, class syntax, object destructuring, and more. All of our modern JS is written in this standard.

Our legacy frontends do not necessarily make use of the syntax improvements and capabilities of ES6, partly because of our outdated build processes in those libraries. We would like to be able to use modern syntax (supported by Blip: babel) in all our frontends to increase developer velocity and happiness, and improve the readability and quality of our code.
35
eslintAdoptedFrontendBen Warzeskisarinayes-lint is a linting utility for modern (ES6) Javascript. Integratable with editors, version control, and build processes. This is our core/default JS style checker for our modern JS projects and should be our standard across all frontends. We have a common eslint config in the @edx/eslint-config package. This config is imported into @edx/frontend-build and made available to all our micro-frontends.
36
Font AwesomeHoldFrontendBen WarzeskisarinayFont Awesome is a large and heavily maintained free icon library. Integrates very easily with React UI development. This is a legacy icon set that we are transitioning away from, but still serves as the basis of our icon library. Rather than using font-awesome, we are building an Open edX-specific icon set in Blip: Paragon icons, and encourage our frontends to adopt that instead.
37
IE 11 supportHoldFrontendDavid JoyAdam Stankiewicz / sarinaYWe continue to support IE 11 in the near term because edx.org and edX for Business continues to have a number of partners and customers which depend on the browser. We are actively working with partners to cut over to more modern browsers so we can drop support. Doing so will allow us to simplify build processes (e.g., transpile less code) and use more modern browser features. The industry is quickly moving away from IE11, as Microsoft itself has signaled their intention to stop supporting it in Microsoft 365 applications in 2021 and officially dropping support for IE11 in Windows 10 in June 2022.
38
JestAdoptedFrontendBen WarzeskisarinayJest is a JavaScript unit testing framework, providing test structures, assertions, powerful mocking functionality, snapshots, and deep coverage reporting. This powers all of our unit tests in our micro-frontends. We use it in conjunction with libraries like Blip: testing-library.
39
JSDocProvisionalFrontendBen WarzeskisarinayJSDoc is a JavaScript documentation tool and standard for writing docstrings for modules, objects, and functions. Some of our libraries model their documentation structure on JSDoc. Notably, Blip: frontend-platform generates its documentation site with JSDoc. Investigation hasn't found any other reasonable tools for JavaScript code comments.
40
LernaProvisionalFrontendBen WarzeskisarinayLerna is a web-package build tool that optimizes the workflow around maintaining and managing multi-package repositories with git and npm. We have considered using Lerna in several repositories, such as Paragon. It has been adopted for a few packages, but is not widely used, as the vast majority of the frontend code is broken up into module/library-specific Git repositories.
41
lodashAcceptedFrontendBen Warzeskisarinaylodash is a JavaScript utility library providing a wide variety of quality-of-life improvements to working in JS code, particularly utilities for working on strings, objects, and arrays that are available in other languages. Some of the prominence of this tool has faded as ES6 has brought more power to the base JS syntax. Our recommendation is to individually install lodash functions in micro-frontends and libraries as necessary, but to avoid installing the entire library at once.
42
MathJaxAdoptedFrontendJeff WittSarinayJS package that renders MathML to HTML or SVG markup. We are using v2.x, will upgrade to v3.x eventually. We use this in a number of our frontend repos for math markup (ORA, in particular).
43
NetlifyProvisionalFrontendAdam StankiewiczsarinaYA cloud computing company that offers hosting and serverless backend services for web applications and static websites. Currently used for Paragon PR deploy previews.
44
npmAdoptedFrontendBen Warzeskisarinay<a href="https://docs.npmjs.com/about-npm">Node Package Manager</a> is an industry standard JavaScript package manager that we use to manage all of the dependencies we use in our frontend applications and libraries. This is a core part of our JavaScript build infrastructure for all projects. We do not use yarn - an alternative - today.
45
ReactAdoptedFrontendBen WarzeskisarinayReact is a powerful JavaScript library for creating user interfaces, allowing you to compose complex UIs from small and isolated/re-usable pieces of code called "components".
This is the core UI framework for all MFE UI development today in the Open edX ecosystem.
46
react-bootstrapAcceptedFrontendBen WarzeskisarinaYA maintained set of React components built around the Javascript UI components available in the bootstrapJS library. These form the underpinning of much of the Paragon component library.
47
React hooksAcceptedFrontendLong LinsarinayReact Hooks are pure JavaScript components written explicitly in functional React components that allow you to access React state and life cycle features from functional components and provide the option to move away from writing classes. Hooks make it easy to extract and reuse stateful logic across components.<br/><br/>

This technique is used in much of our React micro-frontend code. We have found that functional React components with hooks work well for the vast majority of our use cases; however, particularly complex components with event handlers and state management logic sometimes benefit from being written as a class component.
48
react-routerAdoptedFrontendBen Warzeskisarinayreact-router is an industry standard React client-side routing library. It lets you write declarative 'routes' in your frontend that will be rendered without a page refresh when their path matches the path in the URL. We use this in most of our MFEs, and have found it a very effective way of managing sub-pages within a micro-frontend.
49
react-test-rendererProvisionalFrontendBen Warzeskisarinayreact-test-renderer is a testing tool that allows rendering of React components into pure JavaScript objects that can be queried and rendered into snapshots for testing.
In particular, this tool is more powerful for rendering hook-based React components than its counterpart (Enzyme). This tool is used to write unit tests in many of our MFEs and Paragon, and is an important tool in our testing strategy.
50
ReduxAcceptedFrontendBen WarzeskisarinayRedux is a powerful state management library used in many of our micro-frontends. We recommend using it with the redux-toolkit library, which simplifies the implementation and reduces the amount of boilerplate needed to use Redux. Some micro-frontends choose not to use Redux; they opt for simpler state management mechanisms available in React itself, such as component state and prop passing, as well as React context. When to use Redux is a frequent topic of debate. In many cases where a reducer pattern is useful, using Redux and redux-toolkit rather than hand-coding reducers for the `useReducer` hook can - again - reduce boilerplate and help ensure the code follows best practices and is approachable.
51
redux-thunkAcceptedFrontendBen WarzeskisarinayA simple Redux middleware that helps standardize how a frontend application handles side effects and asynchronous tasks. It enables complex data actions to be grouped and gives us a consistent, reusable, predictable place to make API calls outside the React component hierarchy itself. redux-thunk is used widely in our micro-frontends, and has proven itself to be much more approachable than other tools like redux-saga.
52
RenovateAcceptedFrontendBen WarzeskisarinayRenovate is an automated dependency updater for GitHub repositories. Open edX repositories use Renovate to automate updates of frontend packages (the edx-requirements-bot covers Python and other backend packages).
53
requirejsHoldFrontendBen Warzeskisarinayrequirejs is a JavaScript file and module loader used in some of our legacy frontends. It is not used in micro-frontends at all; MFEs use webpack. We should not use requirejs anymore, and should attempt to remove it in favor of webpack wherever possible.
54
SASSAdoptedFrontendBen WarzeskisarinaySASS is a preprocessor scripting language that is compiled into CSS which adds features such as variables, nested rules, inline imports, and more.
The Open edX platform uses SASS extensively, and because of our usage of Bootstrap 4, relies on it for branding.
55
TinyMCEAdoptedFrontendJeff WittSarina/Ben WY<a href=" https://www.tiny.cloud/get-tiny/downloads/">TinyMCE</a> is a Javascript-based rich-text editor, used for allowing users to enter text with rich formatting (as well as adding certain files/images to their submisisons). Used in applications (such as Open Response Assessments) where users wish to be able to submit formatted document-style text content. Note that we have a plugin to make it easier to mark spans with different lang attributes.
56
TypescriptHoldFrontendBen WarzeskisarinayTypeScript is a strict syntactical superset of JavaScript, adding optional static typing to the language. TypeScript requires architectural support and that all associated code is updated to the new paradigm, which can be costly. Some providers in the community favor TypeScript, but we do not currently use it, and have no plans to start. For consistency and the approachability of our codebase, we'd recommend using ES6 unless there is a very compelling reason to adopt TypeScript.
57
WebpackAdoptedFrontendBen WarzeskisarinayWebpack is a JavaScript module bundler, capable of transforming, building, or packaging almost all front-end assets. We use webpack extensively in all of our micro-frontends, and in some legacy frontends co-located with their corresponding backends. Webpack is an industry standard and has proven itself to be very flexible and have a wider variety of available plugins and loaders than other bundlers like rollup or parcel. We expect to continue to invest in our usage of webpack.
58
yarnHoldFrontendBen WarzeskisarinayAn alternative to npm for Javascript package installation. The two have minor differences in speed/performance, security, and implementation. In many of these categories, yarn is slightly ahead of npm, but npm is also keeping pace nicely. There are no current plans to adopt yarn, but it has been posed as an alternative to npm.
59
AnsibleHoldTechnologiesFeanilSarinaYAn infrastructure orchestration tool used to build stage and production application servers from scratch. This technology is being replaced with Docker images in newer services so it no longer has code to build all Open edX services. The Ansible code can be found in the <a href="https://github.com/edx/configuration">Configuration</a> repository.
60
attrsAdoptedTechnologiesNedSarinay<a href="https://www.attrs.org/">attrs</a> is a Python library for writing classes with minimal boilerplate. It inspired the dataclasses module in the Python standard library, but is more full-featured. Attrs is widely considered the best-practice library for minimal-boilerplate classes.
Attrs is best to use when a class is a passive container of data, but is also a good foundation to build on for active mutable objects.
61
blackProvisionalTechnologiesNedSarinaY<a href="https://black.readthedocs.io/">black</a> is a Python code formatter. It offers very few customization options ("You can have any color you want, as long as it is black"). Its goal is to standardize formatting, leaving developers to focus on more important concerns. Black is widely adopted across the Python world. Its lack of customization ensures consistent formatting with no bickering over details. Open edX doesn't yet use black much. Initial adoption requires a massive commit that reformats all files. This interferes with historical analysis of the code (git blame), and so can be controversial, and will also require rebasing all in-flight pull requests.
62
bridgekeeperProvisionalTechnologiesJeremy BowmanSarinaYA full-featured implementation of object-scoped rule-based authorization in Django (e.g., "does this user have characteristics which allows them to perform this kind of action on this database record?"). See <a href="https://open-edx-proposals.readthedocs.io/en/latest/oep-0009-bp-permissions.html">OEP-9</a> for more details.
63
celeryAdoptedTechnologiesFeanilSarinaYA technology for asynchronously performing background tasks in Python. By moving non urgent tasks to celery workers we reduce the load on our application servers and speed up response times to the end users.
64
Circle CIHoldTechnologiesJeremy BowmanSarinaYA continuous integration system which has been popular with some Open edX community members for running tests that edX.org runs in Jenkins. May be losing usage in favor of Blip: GitHub Actions.
65
Confluence docsAdoptedTechnologiesSarinaDavid JoyY<a href="https://openedx.atlassian.net/wiki/home">Confluence</a> is a wiki used by both edX.org internal teams as well as Open edX community members; some pages are private to edX.org while others are public. This wiki is used for documentation of projects and technologies, as well as to facilitate collaboration via shared docs.
66
DjangoAdoptedTechnologiesDave OrmsbeeSarinaY<a href="https://www.djangoproject.com/">Django</a> is the most popular Python full-stack web framework. Django currently powers edx-platform and many other services in Open edX.
67
Django REST FrameworkAdoptedTechnologiesDave OrmsbeeSarinaY<a href="https://www.django-rest-framework.org/">DRF</a> is the most commonly used library for creating REST APIs with Django. Most of our REST APIs have been built using this. We have some older endpoints that accept form posts (e.g. /events) and some REST-like behavior that is manually coded (XBlocks handlers), but we strongly recommend using DRF because of the expertise and tooling we've developed around it.
68
django-rulesHoldTechnologiesJeremy BowmanSarinaYAn early implementation of object-scoped rule-based authorization in Django (e.g., "does this user have characteristics which allows them to perform this kind of action on this database record?"). Blip: bridgekeeper is a newer implementation with more features that we have started switching to.
69
django-storagesAcceptedTechnologiesJeremy BowmansarinayA package which provides a uniform interface for working with (mainly user-uploaded) files in Django, regardless of where the files are actually stored. Allows the use of S3 for production AWS deployments, Swift for OpenStack deployments, local files for development and test environments, etc. by just customizing a few settings.
70
DockerAdoptedTechnologiesAdam Blackwellsarinay<a href="https://www.docker.com/>"Docker</a> is both a company that provides <a href="http://dockerhub.com/">services</a> to edX.org and an open source technology. The open source technology consists of a set of platform as a service products that use OS-level virtualization to deliver software in packages called containers. See more about how edX.org uses Docker <a href="https://openedx.atlassian.net/wiki/spaces/SRE/pages/152797300/Docker">here</a>.
71
ElasticsearchAcceptedTechnologiesJeremy BowmanSarinaYA full-text search engine used for search functionality in several Open edX services. Recently the subject of a licensing spat between the developers and Amazon, it is currently still the market-dominant open source search engine. Open edX primarily uses the latest version compatible with Amazon's hosted offering, although edx.org doesn't currently utilize that offering.
72
Github ActionsAcceptedTechnologiesJeremy BowmanSarinaYA continuous integration system included with GitHub. Being free for open source projects, relatively inexpensive for private ones, and fairly full-featured, this is now our preferred CI system for most projects.
73
GitHubAdoptedTechnologiesJulia EskewSarinaYService provider for software development and version control using Git. Github offers the distributed version control and source code management functionality of Git, plus additional features. All Open edX repositories are hosted in Github and most repositories are in the <a href="https://github.com/edx">edx</a> organization, though some are in the <a href="https://github.com/openedx">openedx</a> organization.
74
GraphQLProvisionalTechnologiesJulia EskewSarinaY<a href="https://graphql.org/">GraphQL</a> is both: <ol><li>a query language for APIs</li><li>a runtime for fulfilling those queries with your existing data</li></ol>GraphQL allows an API caller to specify the exact data they need returned and organizes an API by types/fields instead of endpoints. New types/fields can be added without a new API version. GraphQL is designed to build APIs that are more flexible than a fixed list of REST endpoints. The Open edX platform currently uses REST API endpoints instead of GraphQL.
75
gunicornAdoptedTechnologiesDave OrmsbeeSarinaY<a href="https://gunicorn.org/">Gunicorn</a> is a Python WSGI (Web Server Gateway Interface – a standard Python interface for web apps/frameworks) HTTP server. Open edX uses this to run Django services in production environments. If we start using async views and channels in our Django services, we will need to adopt an ASGI (Asynchronous Server Gateway Interface) server like daphne or uvicorn.
76
isortAdoptedTechnologiesJeremy BowmanSarinaYA linting utility which can report violations of an established set of rules for sorting Python code imports, and optionally fix them automaticaly. Used in continuous integration for many Open edX repositories.
77
JenkinsHoldTechnologiesJeremy BowmanSarinaYA usually self-hosted automation server, often used for continuous integration or recurring scheduled tasks. Very flexible but somewhat difficult to maintain; edX.org is actively trying to reduce the number of things they use it for.
78
makeAdoptedTechnologiesGabe Mulleysarinay<a href="https://www.gnu.org/software/make/manual/make.html">make</a> is a standard tool available on most development and deployment systems. Allows the definition of common sequences of shell commands that are run frequently during development using a "Makefile". Used to provide a standard and expected interface across different development environments.
79
MarkdownAcceptedTechnologiesDavid JoysarinayMarkdown is a lightweight markup language commonly used in the JavaScript ecosystem. While our standard for documentation is RST as documented in <a href="https://github.com/edx/open-edx-proposals/blob/master/oeps/oep-0019-bp-developer-documentation.rst#format">OEP-19</a>, we've found that Markdown is the only option in some specific cases in our frontend ecosystem. The Paragon and frontend-platform docs sites in particular both utilize Markdown because RST-based tooling didn't exist to generate those sites.
80
memcachedAdoptedTechnologiesDave Ormsbeesarinay<a href="http://memcached.org/">Memcached</a> is a key-value cache server, used to enhance performance. Also used by some services to store session data.
81
MongoDBHoldTechnologiesDave Ormsbeesarinay<a href="https://www.mongodb.com/">MongoDB</a> is a document database server, currently used to store course content and forums discussion data.
82
MySQLAdoptedTechnologiesDave Ormsbeesarinay<a href="https://www.mysql.com/">MySQL</a> is Open edX's primary transactional SQL database. Though the Django ORM insulates developers from most of the details, Open edX schemas and practices have been tweaked to accomodate the operational characteristics of this database at scale over the years. The most common database for Django is Blip: PostgreSQL.
83
neo4jProvisionalTechnologiesDave Ormsbeesarinay<a href="https://neo4j.com/">Neo4j</a> is a graph database, currently used for ad hoc queries of course content via CourseGraph.
84
nginxAdoptedTechnologiesDave Ormsbeesarinay<a href="https://www.nginx.com/">Nginx</a> is a web server that is used both for serving static assets and as a reverse proxy for Django services running in gunicorn. It is used primarily for performance reasons. Nginx buffers requests to these services so that slow clients cannot tie down workers. It also has more efficient static file handling than Open edX's Python stack.
85
node.jsAdoptedTechnologiesJeremy BowmansarinayA JavaScript execution environment that can be used from the command line. Often used to implement web services, Open edX primarily uses it for industry-standard tooling to build and test frontend JavaScript code and optimize static assets for deployment. We do not use Node to write micro-services.
86
nosqlHoldTechnologiesJulia Eskewsarinay<a href="https://www.mongodb.com/nosql-explained">NoSQL</a> is a type of database that stores and retrieves data without needing to define its structure (schema) first. This type of database is an alternative to the more rigid relational database, which can be queried using SQL but needs a rigid schema of tables and fields defined before storing data. Open edX uses Blip: MongoDB as a noSQL database to store JSON documents describing course content and forum threads/comments.
87
openapiProvisionalTechnologiesJeremy BowmansarinayA specification for describing web APIs, derived from Blip: Swagger. Some of the Open edX API documentation follows this specification.
88
PactProvisionalTechnologiesJeremy BowmansarinayA framework for consumer-based contract testing, which helps prevent inadvertent breaking changes to actively used web APIs (without requiring slow and difficult to maintain browser automation tests). Usage for Open edX has been discussed for years, and an implementation is now being piloted by an edX.org squad.
89
PostgreSQLProvisionalTechnologiesJeremy BowmansarinayThe most popular relational database for most Django projects other than Open edX, <a href="https://www.postgresql.org/">PostgreSQL</a> offers much of the functionality that Open edX currently uses MongoDB and Elasticsearch for. PostgreSQL has been successfully used by some Open edX installations, but isn't officially supported (primarily because it wasn't supported by Amazon's RDS when edx.org was first lauched).
90
pylintAdoptedTechnologiesNedsarinay<a href="https://www.pylint.org/">pylint</a> is the most full-featured standalone Python linting tool. Open edX uses it to catch common errors and style violations in Python code. This frees people to focus their code reviews on more substantive concerns.
91
pytestAdoptedTechnologiesNedsarinay<a href="https://docs.pytest.org/">pytest</a> is the Python test framework Open edX uses for automated Python testing. It is widely adopted through the Python world, and boasts an impressive array of features.
92
Read The DocsAdoptedTechnologiesNedsarinay<a href="https://readthedocs.org">Read The Docs</a> is a web service offering hosting for documentation. Open edX uses it to publish Blip: ReStructured Text documentation.
93
RedisAdoptedTechnologiesJeremy BowmansarinayA high-performance key-value store. Open edX uses it by default as a Blip: celery broker, and has considered switching to it from Blip: memcached as a cache server (as it would remove a distinct service from the architecture and allow the cache to persist through process restarts).
94
reStructured TextAdoptedTechnologiesNedsarinay<a href="https://en.wikipedia.org/wiki/ReStructuredText">ReStructured Text</a> is a markup format similar in spirit to Markdown. Open edX uses it for documentation, including OEPs, ADRs, and README files. It includes a breadth of capabilities that let it scale well across those different uses.
95
RubyHoldTechnologiesJeremy BowmansarinayA programming language particularly popular due to the Ruby on Rails web application framework. Open edX's discussion forums utilize an old fork of a Ruby on Rails forums service, but work is in progress to support pluggable forum implementations that are more actively maintained and/or use technologies more commonly utilized by Open edX.
96
SwaggerAdoptedTechnologiesJeremy BowmansarinayA tool for generating HTML documentation for web APIs. Used in some Open edX repositories to document the APIs they expose to web front ends, mobile applications, and automation scripts.
97
TransifexAdoptedTechnologiessarinaDavid JoyY<a href="https://www.transifex.com/open-edx/edx-platform/">Transifex</a> is a crowd-sourced translations platform used by Open edX to facilitate translating platform text from English to a variety of other languages. At this time, Transifex is not used for translating course content or technical documentation.
98
Travis CIHoldTechnologiesJeremy BowmansarinayA continuous integration system previously popular for automated tests of open source projects. It is now less actively maintained and has worse terms of service after being acquired by another company, so Open edX is now actively switching to Blip: GitHub Actions instead.
99
UbuntuAdoptedTechnologiesJeremy BowmansarinayA very popular distribution of the Linux kernel and associated code, derived from the volunteer-run Debian distribution but adding commercial support and more frequent releases. Most Open edX services are intended to be installed on this operating system.
100
BlockstoreProvisionalOpen edXDave Ormsbeesarinay<a href="https://github.com/edx/blockstore">Blockstore</a> is a learning objects repository developed for the next version of content libraries, and intended as a long term replacement for modulestore.