-
Notifications
You must be signed in to change notification settings - Fork 315
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’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Refactor Session Recording Proxy Configuration #475
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the move here would be to allow each endpoint to specify its own api host, the way we currently allow them to specify their own paths with the api_routes
config. You might do this by adding an api_hosts
config parallel to the api_routes
one (and let those take precedence over the api_host
config if present).
Good idea. I'll take a swag at that in a few |
@tdumitrescu
If/when merged, the config URL shouldn't be a problem but I wanted to see if there was an easier way to config/point to a source (CDN or local in-app asset) |
I'm not sure what that means. The way to switch the location of the mixpanel-recorder bundle for development is to use that config option, e.g.: mixpanel.init('my token', {recorder_src: 'https://url.of.local.dev.sdk/build/mixpanel-recorder.js'}); |
🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <[email protected]>
@tdumitrescu Refactored out the single use config override; added |
Summary
This PR changes how Mixpanel session recording determines whether to use a proxy when sending data. It adds a semantically clear session_recording_use_proxy parameter to direct the heavy
usage/recording
payloads to the proxy with a default offalse
. If true, it ships to the proxy; else default behaviour.Changes
Added session_recording_use_proxy configuration parameter (default: false)
Defaults to the direct route to Mixpanel (which is the optimal path for most users)
Why this change?
When using the
api_host
proxy for capturing/forwardingusage/*
events, issues were had trying to pass through the relatively largeusage/record
event/payloads. Instead of incurring the throughput, its simpler/cleaner to just shipusage/record
events straight to mixpanel.