[RUM-14242] Introduce event bus pattern for data processing

[cdn34dd]

Motivation

Create an event management system to handle the various types of events required by the SDK where all the main event handlers are decoupled from each other and self select which events to handle.

Communication happens through a central hub that acts as dispatch point.

Changes

Adds EventManager class and defines the required types and constants necessary for its use.

Test instructions

In order to use this system, we must first instantiate the EventManager and the required handler classes like so:

const eventManager = new EventManager();
const handler: EventHandler<Event> = {
      canHandle: ...,
      handle: ...,
};
eventManager.registerHandler(handler);

const event: Event = {
      track: EventTrack.TRACE, 
      source: EventSource.MAIN,
      status: EventStatus.RAW,
      data,
}
eventManager.notify(event);

Checklist

• Tested locally (playground)
• Added unit tests for this change.
• Added e2e/integration tests for this change.

[datadog-datadog-prod-us1]

⚠️ Code Quality    ✅ Code Vulnerabilities    ✅ Library Vulnerabilities

✨ Fix all issues with Cursor

⚠️ Warnings

🛠️ 4 Code quality issues detected

Medium: typescript-best-practices/no-console (Fix with Cursor)

Avoid leaving console debug statements View rule
src/transport/http.ts:15

Low: typescript-code-style/no-new (Fix with Cursor)

Avoid new operators outside of assignments or comparisons View rule
src/index.ts:25

Low: typescript-code-style/no-new (Fix with Cursor)

Avoid new operators outside of assignments or comparisons View rule
src/index.ts:24

Low: typescript-code-style/no-new (Fix with Cursor)

Avoid new operators outside of assignments or comparisons View rule
src/index.ts:23

View all

ℹ️ Info

🛡️ No new code vulnerabilities
📚 No new vulnerable libraries detected

_{This comment will be updated automatically if new data arrives.
🔗 Commit SHA: 042ef39 | Docs | Datadog PR Page | Was this helpful? Give us feedback!}

[bcaudan]

Early review:

scope:

I think we could limit this one to EventManager introduction only. we could deal with assembly, trace processing, ... in subsequent PRs.
We could have the createDummyViewEvent notify event and sendEvent handle them for now.

API:

• register pattern:

💭 I am expecting some classes to registerHandler and notify, I wonder if may not be more convenient to pass the EventManager as a dependency and let the class register its handler rather than implement the handler interface.

const eventManager = new EventManager();

const assembly = new Assembly(hooks, eventManager);


class Assembly {
  constructor(...) {
     this.eventManager.registerHandler({
         canHandle: (event: Event) => event.status === RAW,
         process: this.processRawEvent
      })
  }
}

it could also allow one class to register multiple handlers which could provide some flexibility.

• handle VS process:

Any intent with differentiating handle and process?

• Event:

I would like to introduce some lifecycle events at some point, like session expired / session renew. Do we think we should use the same event manager or split lifecycle and collected events?

[bcaudan]

What about using Event manager with CreateDummyEvent and sendEvent to have a first integration with it?

[bcaudan]

💬 suggestion: ‏what about using endpoint naming for consistency?

Suggested change

	export const EventTrack = {
	LOG: 'logs',
	RUM: 'rum',
	TRACE: 'spans',
	} as const;
	export const EventTrack = {
	LOGS: 'logs',
	RUM: 'rum',
	SPANS: 'spans',
	} as const;

[bcaudan]

💬 suggestion: ‏does not seem to be used for now

Suggested change

	export const EventType = {
	LOG: 'log',
	RUM: 'rum',
	TRACE: 'span',
	} as const;

[bcaudan]

💬 suggestion: ‏instead of kind and status, what about only using kind? not sure that Raw and Server event need to share the same properties

RawEvent {
  kind: 'raw'
  source
  data
}

ServerEvent {
  kind: 'server'
  track
  data
}

LifetimeEvent {
  kind: 'lifetime'
  data
}

[bcaudan]

💬 suggestion: ‏In browser sdk, we are using the LifeCycle naming which seems more appropriate to me than Lifetime for events like "end user activity", session renew", ...

[bcaudan]

💬 suggestion: it is not obvious to me that we already need to introduce:

• handling of multiple events though notify
• calling notify from the handler

I think we could keep things simple at first, see how we end up using it and add more complexity along the way‏

[cdn34dd]

I don't think having a bit more flexibility in the implementation at this point is an issue. As for the notify from the handler, that goes allow what we discussed previously on how data should flow, I could have misunderstood something, but then we should resync to make sure were aligned on what we're aiming for.

[bcaudan]

Nice!