Guidelines for proactive vs reactive event definitions in openedx-events

[robrap]

The Open edX platform includes many types of events, and this post is specifically addressing event signals in this repo. These are mainly used for plugins within a service, or to put on the event bus for cross-service communication.

Most of my experience from the event bus work has been with what I'll call "reactive event definitions", which are signal events that were added once a known consumer needed the event. It is possible that some of the earlier events were implemented more proactively, where we weren't sure when and if there would be a consumer, but were making the events available just in case.

A question has arisen as to whether we should proactively be publishing create/update/delete events for all key models as part of their public API, and I'm wondering what others think.

[robrap]

Note: this ticket was advertised in https://discuss.openedx.org/t/guidelines-for-proactive-vs-reactive-event-definitions-in-openedx-events/10661, which may or may not collect its own comments.

[felipemontoya]

Back when we had the earliest draft of what eventually became OEP-50 we had a list of possible places in the code where we would want to extend based on common key models of the platform.
You can still find those in the google doc that is linked from oep-50. https://docs.google.com/document/d/1jhnudz6AVtVt0ZSRSwOwj9gJ0lsDDn_8mUCPehLPzLw/edit#heading=h.vo2ywbxdhh5

I think that as long as we are reasonably going to keep them supported for a while the more available events the better. Ideally as an extension or consumer developer I should be able to first look at the list of available events hoping to find that the one I need is already present. Having to include the event in the core first in order to be able to extend it later has two negative consequences IMHO.

• to avoid doing the double work I might be tempted to use a different arquitecture and end up never publishing the event.
• the data passed to the event might be too specific for my current use case. We try to discuss this when the event is being created at this repo, but we might not always catch that.

[robrap]

Thanks @felipemontoya. If we were to document your stance and reasoning, we would just need to find a good home for it in the existing docs.