Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: consider accepting the navigator.userAgent string in the dataplane API #294

Open
JoshBarr opened this issue Nov 15, 2022 · 2 comments
Labels
enhancement New feature or request

Comments

@JoshBarr
Copy link

Hello 馃憢

I'm implementing RUM monitoring for a library that's deployed on a number of websites. For this use-case, the final bundle size is of critical importance. I noticed that RUM is bundling ua-parser-js (approx 6kb gzipped) to obtain information about the navigator. Unfortunately this adds too much weight for me to include within the performance budget for my library.

Could the RUM dataplane API accept the raw user agent string as a metadata property, instead of parsing this information into separate fields on the client-side?

@qhanam
Copy link
Member

qhanam commented Nov 18, 2022

Hi Josh, agree this is would be a good enhancement. Out of curiosity, what is your budget for RUM in your library (compressed/uncompressed)?

@JoshBarr
Copy link
Author

We've written a very minimal custom RUM client that fits in about ~4kb gzipped. We only really need this RUM instance for error tracking on sessions, it doesn't need x-ray or web vitals. This library is running on pages that may have their own RUM solution already (either AWS RUM or another vendor), so we want to avoid loading multiple RUMs on the page.

We plan on improving on this total size by shifting some functionality into a lambda that forwards requests to the monitor instead. I think we can shift sigV4 signing, authentication, and UA parsing over to the lambda. The client-side JS would then only be responsible for emitting simple event payloads to an unauthenticated endpoint.

In general, for libraries with lots of optional functionality, I really dig it when it's possible to build your own. This gives bundlers the best possible chance of shaking out everything you're not using, and the option to skip polyfills if you don't need them:

import { baseClient } from "rum/base"
import { xray } from "rum/xray"
import { vitals } from "rum/vitals"
 
const client = baseClient.configure({
  plugins: [
    xray({ /* xray options */ }),
    vitals({ /* vitals options */}),
  ],
  // inject native implementations for things that are typically polyfilled
  browserApis: {
    uuid: crypto.randomUUID,
    sha256: (message) => crypto.subtle.digest('SHA-256', new TextEncoder().encode(message)),
  }
})

/* leanest, meanest client that fits my exact needs 馃  */

@qhanam qhanam added the enhancement New feature or request label Jul 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants