After the slack thread here, I had the good fortune of rounding up with @dave and @robrap this morning to talk a little about the architecture components of sending our analytic events over the event bus. We covered a lot of ground about the current state of the event bus, and ideas for the future.
Overall, though, I think that we’ve hit a consensus that for now we’d like to avoid sending ALL tracking logs over the bus and instead focus on post-transformed xAPI events. Effectively using the bus as a more robust async delivery mechanism for xAPI statements to the LRS and allowing other consumers of the anonymized-by-default learning traces if desired.
I believe we’ll be using event-routing-backends as the producer for these events, and it will be able to subclass OpenEdxPublicSignal as usual to send wrap the sending. We discussed sending all xAPI statements as a single “type” with a fairly generic payload so that changes to xAPI statement schemas don’t need to also be propagated to the Avro schema layer.
A lot of this depends on implementation details of the message bus, which will evolve as we develop the Redis bus, but I wanted to get the rough details in front of everyone and make sure Robert and Dave have a chance to clear up any of my misconceptions.
A question that I have is whether y’all are recommending a hard distinction between logging and state propagation. There’s currently an event in Open edX events for capturing learner enrollment. There’s also an adapter for translating the dictionary form into Avro as expected by the Event Bus.
As I understand the recommendation, it would be fair game for the state, after having been translated to xAPI, to be put on the Event BUS.
However, do you envision that in the future other Open edX services would receive state updates via xAPI? Or would you say, xAPI is just for “logging learning traces” and state changes are handled via the avro form exclusively?
I worry that we have multiple ways of representing the same state changes, that that will introduces errors and be difficult to maintain into the future.
That’s a fair worry. The format of the xAPI events and their anonymized-by-default nature is less likely to be useful to consumers on the bus than their openedx-events equivalents. The design of putting all of the xAPI statements on one stream would also be a deterrent, unless someone is using the bus in the place of an LRS to broker events to a database. I can see a world where we have 2 consumers for the xAPI stream- one which simply logs them to a durable object store like S3 for replay / debugging / auditing, and one that communicates with the LRS.
We already have multiple ways of representing state changes (sync & async API calls, message bus, local signals) and xAPI on the bus would likely be the least convenient way of dealing with them, except in the case where something already exists in xAPI and would need to be created in openedx-events. For that we should document in several locations why they should just create a new event instead of tapping into the firehose of learning traces.
