Topics
3 Review Needed Architecture Investments
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?
Hackathon summary
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
For Pilot
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
Time-to-Develop
Reduction on transactions to Discovery service
For Production
Granularity of messages
Naming of exchanges, messages, etc.
Transport layer: Redis vs Kafka
Open questions
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?
Login MFE
So many teams that spun up new MFEs! OMG!
Currently, very edX-specific.
7 Open edX and MFEs
Missing gaps
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
Devstack
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))
Documentation
APIs
documenting, testing
Juniper
MFEs will be open-sourced and tagged as part of the release
Deployment questions may still remain
Deprecation of old after Koa