Optimization on bridge routes#196
Optimization on bridge routes#196joaolcorreia wants to merge 1 commit into190-amplitude-sdk-supportfrom
Conversation
| collectorService = collectorService | ||
| ) | ||
| val bridgeRoutes = collectorService.bridges.foldRight[Route](reject) { (bridge, acc) => | ||
| bridge.route(ctx) ~ acc |
There was a problem hiding this comment.
While this looks cleaner, it still composes a chain of Pekko directives that are evaluated left-to-right until one matches. In the worst case, this is still O(n), not O(1). To achieve true O(1) dispatch, we'd need to extract the path parameters and use a Map lookup to select the appropriate bridge, rather than chaining routes.
There was a problem hiding this comment.
So we need to maintain something like Map[(String, String), Bridge], with vendor/version pairs listed (we can store those mapping in a config to make it more dynamic)
| contentType: Option[ContentType] = None, | ||
| spAnonymous: Option[String], | ||
| analyticsJsEvent: Option[AnalyticsJsBridge.Event] = None, | ||
| amplitudeEvent: Option[AmplitudeBridge.AmplitudeEvent] = None |
There was a problem hiding this comment.
Just noticed this one. If there will be more bridge types, this won`t look clean if extending. Maybe introduce a generic class or sealed trait for event params, and inherit specific ones. Then use pattern matching to detect and use exact one when reading exact values.
2 participants
The goal here is to support multiple bridges with minimal penalty, which this refactor achieves. For performance this also tries the default collector routes first and avoids future changes to core collector files.