chore: dispatch all events to EventBus

[williazz]

Rewrite of #440

Purpose

This PR creates the structure necessary for sharing information between plugins.

Uses cases:

1. Have PluginA find eventId's created by PluginB etc. Useful for LCP attribution
2. WebVitalsPlugin tracks current count of in-flight Xhr and Fetch requests

Revisions

Revision 1

I have created EventBus with topic-based filtering. I implemented our own instead of taking on a dependency because we only need a few extremely simple features.

• Plugins can subscribe to any topic via context.bus.subscribe(topic, callback)
• Plugins can publish to any topic via context.bus.dispatch(topic, message)
• All events are published on every record by EventCache via bus.dispatch(eventType, message)

Revision 2

• Plugins are responsible for dispatching events
• EventCache is not responsible for dispatching events
• EventCache.record returns a ParsedRumEvent so plugins can access things like eventId, metadata, details, etc.
• Read this thread for full context https://github.com/aws-observability/aws-rum-web/pull/445#discussion_r1317539603

Revision 3

• EventCache dispatches every event that is successfully recorded to topic 'events'
• Resource event supplies additional key=PerformanceResourceTiming
• Navigation supplies additional key=PerformanceNavigationTiming for level 2
• Read for full context https://github.com/aws-observability/aws-rum-web/pull/445#discussion_r1317539603

Revision 4

• Remove key
• Target main branch

  Examples

Use case 1: PluginA finds eventId's of events from PluginB

class WebVitalsPlugin {
   imageEvents = []
   constructor() {
      this.context.bus.subscribe(PERFORMANCE_RESOURCE_EVENT, this.storeResourceEvent)
   }
   storeResourceEvent(event) {
      if (event.fileType === ResourceTypes.IMAGE) {
         this.imageEvents.push(event)
      }
   }

   ...
   onLCP(payload => {
       ...
       findMatchingLCPEvent()
       // teardown
       this.imageEvents = []
       this.context.bus.unsubscribe(...)
   })
}

Use case 2: Count in-flight fetch/xhr requests

// FetchPlugin.ts
...
private fetch() {
   ...
   this.context.bus.dispatch('http_open_count', {payload: 1})
   return original()
   .apply()
   .then(() => {
        this.context.bus.dispatch('http_open_count', {payload: -1})
    })
   .catch(() => {
        this.context.bus.dispatch('http_open_count', {payload: -1})
    })
}

...

// WebVitalsPlugin
class WebVitalsPlugins {
    ...
    http_open_count = 0
    handleHttpCountChange({payload}) { this.http_open_count += payload }
    constructor() {
        this.context.bus.subscribe('http_open_count', this.handleHttpCountChange)
   }
   teardown() {
       this.context.bus.unsubscribe('http_open_count', this.handleHttpCountChange)
   }
   ....
}

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[ps863]

high level question: could the addition and usage of an event bus impact the memory/performance footprint of the web client on web applications?

[williazz]

high level question: could the addition and usage of an event bus impact the memory/performance footprint of the web client on web applications?

We are currently only monitoring the size and relying design principles to limit memory and cpu usage. I have also been thinking about how to objectively monitor this performance.

But from a design perspective, I think the impact is minimal.

[qhanam]

My thoughts on (1) vs (2): If doing (1), this topic allows any plugin to listen for any event. Publish all events under an ‘events’ topic. If doing (2), this topic is for the specific purpose of tracking resource/nav event Ids. Return the event id from recordEvent and publish an <event id, url> tuple.