3 Review https://openedx.atlassian.net/wiki/spaces/AC/pages/1165461538
4 Review https://www.thoughtworks.com/radar/techniques
Hackathon project follow-ups
7 Review Async Messaging Hackathon results
Are there other teams that could make use of this effort and move to use this pattern?
Created Producers in discovery; sent messages to Redis; Consumers in Registry. Discovery → Redis + Celery-Konbu → Registry
Django signal in Discovery; post-save sends a message.
Each service has its own messaging container
JSON format of messages
Current tickets in the Enterprise backlog created by @Christopher Pappas
Add the producer code to Discovery
Add the consumer code to Enterprise Catalog
Versioning of messages
Timestamps in the body of messages
Define the schema for the message body
Make it clear with Product that this is a proof-of-concept
Rubric to measure success → for further adoption by the org
Reduction on transactions to Discovery service
Granularity of messages
Naming of exchanges, messages, etc.
Transport layer: Redis vs Kafka
Would this eventually supersede the need for celery?
They do serve different needs.
How do we handle fired events from transactions that were eventually rolled back?
Integration with Amazon’s SQS?
So many teams that spun up new MFEs! OMG!
Currently, very edX-specific.
7 Open edX and MFEs
Deployment - not in Open edX native installation
Like to enable the community
Nim plans to write a Discourse thread to explain the situation including the advantages of MFEs and missing gaps
Part of the Courseware MFE Epic to figure out running MFEs out-of-the-box on Devstack
Connect with @Kyle McCormick since he has a prototype on putting multiple MFEs in a single container. (@Adam Butterworth (Deactivated), @David Joy (Deactivated))
For Open edX: https://openedx.atlassian.net/wiki/pages/createpage.action?spaceKey=FEDX&title=Micro-frontend%20applications%20in%20Open%20edX
MFEs will be open-sourced and tagged as part of the release
Deployment questions may still remain
Deprecation of old after Koa