-
Notifications
You must be signed in to change notification settings - Fork 21
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
docs: adr for enabling producing to event bus via settings
- Loading branch information
1 parent
7afe333
commit ca804fc
Showing
2 changed files
with
75 additions
and
0 deletions.
There are no files selected for viewing
74 changes: 74 additions & 0 deletions
74
docs/decisions/0011-producing-to-event-bus-via-settings.rst
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,74 @@ | ||
11. Enable producing to event bus via settings | ||
############################################## | ||
|
||
Status | ||
****** | ||
|
||
**Provisional** 2023-05-23 | ||
|
||
Context | ||
******* | ||
|
||
Since the initial implementation of the event bus allowed only a single event type to be published to a topic, details like topic name, consumer group name, and consumer name were configured via code. The current implementation of openedx-events does not actually push any events to the underlying implementations like `edx-event-bus-kafka`_ and `edx-event-bus-redis`_. The event-producing application is expected to create a signal handler (since openedx-events subclasses Django signals) to catch the event and push it into the event bus. Some examples of the handlers: `handlers example`_. | ||
|
||
.. _handlers example: https://github.com/openedx/edx-platform/blob/27b8d2f68d5dfaf84755e7d7f8dccc97ce3be509/cms/djangoapps/contentstore/signals/handlers.py#L162-L210 | ||
.. _edx-event-bus-kafka: https://github.com/openedx/event-bus-kafka | ||
.. _edx-event-bus-redis: https://github.com/openedx/event-bus-redis | ||
|
||
This ADR aims to propose a solution for configuring the details, like the topic name, consumer group name, etc. via Django settings as well as pushing events to the event bus without requiring the producing application to write additional handlers. | ||
|
||
|
||
Decision | ||
******** | ||
|
||
Create a generic signal handler to push events to the event bus. This handler should be attached to or connected to the signals that are enabled in Django settings. The configuration format will be as shown below: | ||
|
||
.. code-block:: python | ||
OPEN_EDX_EVENTS_CONFIG = { | ||
'org.openedx.content_authoring.xblock.deleted.v1': { | ||
'topics': 'xblock-status', | ||
'event_key_field': 'xblock_info.usage_key', | ||
'event_data_key': 'xblock_info', | ||
'enabled': True, | ||
}, | ||
'org.openedx.content_authoring.xblock.published.v1': { | ||
'topics': ['xblock-status', 'xblock-published'], | ||
'event_key_field': 'xblock_info.usage_key', | ||
'event_data_key': 'xblock_info', | ||
'enabled': True, | ||
}, | ||
} | ||
This configuration will be read in openedx_events ``apps.OpenedxEventsConfig(AppConfig).ready`` method and a generic signal handler will be connected to the event_types (keys) listed in the configuration after validating its format. | ||
|
||
.. code-block:: python | ||
def ready(self): | ||
load_all_signals() | ||
config = read_config() | ||
for configured_signal in config: | ||
connect_or_disconnect_handlers(configured_signal) | ||
The generic handler will again read the configuration and get details for event or signal triggered and push it to the event bus. | ||
|
||
.. code-block:: python | ||
def general_signal_handler(sender, signal, **kwargs): | ||
config = read_config(signal) | ||
for topic in topics: | ||
push_event_to_implementation(signal, config) | ||
Consequences | ||
************ | ||
|
||
* Applications producing to event_bus can push events without requiring any additional code. | ||
* Users can push related events to the same topic, which will allow them to run a single consumer and process the events in the correct order. | ||
* The configuration is a dictionary, which makes it flexible but difficult to enforce schemas and maintain them. | ||
* Producing as well as consuming applications will be required to add ``openedx_events`` as an application in their ``INSTALLED_APPS`` settings. | ||
|
||
Rejected Alternatives | ||
********************* | ||
|
||
* Implementing configurable handlers in the host applications will require repeating the code in each host application. | ||
* Following the current way of using fixed handlers will force users to create multiple consumer processes for consuming multiple events, and hence the order of execution is not guaranteed across events. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters