-
Notifications
You must be signed in to change notification settings - Fork 140
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
feat: Allow setting asset_host separately from api_host #942
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.
Not sure if this is the way to go... if we ever wanted it to be a universal change, we would have to get every user to add an additional config item. 🤔
Could we write out the various configurations we expect to get to and what they solve first? (Just trying to reduce the work and confusing setups that users have to implement as we end up stuck with them for basically forever...)
Follow up thought - part of the thing here is to make sure that blockers don't add blocks to non-tracking domains (leading to our web app or other parts being broken). I feel like adding a new assets host will just make it clear "oh these are more hosts we should block" which just exacerbates the problem right? In my mind best would be to have tracking assets and tracking endpoints linked together as a default. That way tracker-blockers (that we have to live with) don't block anything they shouldn't, and if someone uses a reverse proxy, then the chances of successful tracking increase as both assets and tracking goes via that route? Which again comes down to my general thought - how does a separate assets host actually benefit us at all? 😅 |
the idea is:
the main reason for separate hosts is to have a CDN on static assets but not the api endpoints |
Size Change: +968 B (0%) Total Size: 753 kB
ℹ️ View Unchanged
|
17511bd
to
8b4016f
Compare
I still feel like we need a tracking-specific CDN for those assets, otherwise eventually it will get added to a block list and then our whole app will be broken again |
This PR hasn't seen activity in a week! Should it be merged, closed, or further worked on? If you want to keep it open, post a comment or remove the |
This PR was closed due to lack of activity. Feel free to reopen if it's still relevant. |
Changes
Currently we fetch static assets from the api_host. This has a bunch of issues and we'd like to separate these (so that e.g. static assets can be behind a CDN but not the API)
Checklist