[Feature Request]: URL normalization

[gerardaz]

Please provide your feature request

Right now, if I'm not mistaken, there's no way to normalize two different paths that may be canonically the same path: either because they are aliases of each other, or because they contain a parameter that should be ignored.

For instance, in an SPA, with a paramaterized path of /resource/:id I may not want to consider all values of :id as separate paths: if this is something like a UUID, it's almost certain that I don't want to consider them as separate paths because it will make reporting so noisy as to become useless

From what I can see, there isn't currently a way to specify an overwrite for the path for RUM reporting purposes, but this feels sorely needed.

[qhanam]

If I understand correctly, this needs to be done by the application code (client-side), since CloudWatch RUM doesn't currently have the ability to group or filter URLs server side.

A hook should be added to the router of whatever framework you are using (Angular/React/Vue/etc.). When the hook is called, record the page Id and filter out any high-cardinality or sensitive data.

The aws-rum-web docs have examples for React and Angular(be sure to also set disableAutoPageView: false. You may also find the blog "Using Amazon CloudWatch RUM with a React web application in five steps" helpful. It discusses integrating CloudWatch RUM into a React application and includes a section titled "Step 4: Omit user ID from page views".

[gerardaz]

So does recording them manually affect all RUM data? This wasn't very clear from the documentation (or at least my understanding of it so that could be on me).

I kind of assumed it will only affect the page view events, not other events. But the example given with the user ID I guess suggests that's not the case, and it affects all data?

If so, I can work with that for now, but could you consider adding something client side? A URL processing callback or something, so we don't have to put the code inline.

In a React router app, this is actually non trivial to implement in a scalable way. Because if you have (as I do) something like

const MyApp = () => {
return <Router>
  <Route></Route>
 </Router>
}

the natural place you'd want to put it is at the top level, inside MyApp. But here we don't actually have access to the Router (because it's outside the Router provider), so you can't use the built-in hooks that would tell you what raw path (i.e. without interpolating params) it matched.

So you have to then start hooking into the browser's navigation events, and then putting all this rewrite code here. When RUM is hooking into that for you by default: you just need some way to normalize parameterized URLs (this doesn't quite solve the problem of using the native Router hooks that would normalize it for you but I'll take what I can get)

[limhjgrace]

Hi @gerardaz, yes manually recording page views (I'm assuming you're reference this doc: https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-RUM-modify-snippet.html) does affect the pageId that's added to all RUM data. I think this should be enough to get you unblocked.

Depending on the number of pages you have in your application, this may require non-trivial amount of work. We could explore updating the client configs to accept a callback, could you provide an example of said callback? I was thinking that there might not be a one-size fits all solution but unique callbacks specific to a page so wanted to verify via your example.

[gerardaz]

Yeah for sure, I get that. My thought was just a really simple callback like (page: string) => string

Any pivots you need to do per-page could be handled by this – you could have extended helper functions called within it

For me the biggest risk of our current implementation is that, within React Router, we cannot observe the router at the top. And since we're doing URL normalization on all pages, based on the routing setup (e.g. /shared/:shareId is matched by /shared/378yfrtq378fhec/) this means redundant capturing and potentially forgetting to reimplement