🦔 PostHog provides open-source web & product analytics, session recording, feature flagging and A/B testing that you can self-host. Get started - free.
Generally the idea is that the new flags service will replace the "decide" django endpoint with a much more scalable solution. The thing it won't do necessarily is handle the "remote config" side of things which is currently the other main use for decide.
My idea is to generate the "config" parts into a dedicated helper model which takes care of creating this config derived from the various settings allowing us to do a few cool things:
Serve the config as a static file via a CDN - no hot servers needed
Back support /decide filling in from the same highly cached concept
Build an additional file which is a token-scoped file containing all of the config and all of the posthog-js (one load to rule them all)
Allow us to GTM style things for the destinations to inject extra JS loading in a hyper optimal way
Changes
This PR is just part 1 - generate the RemoteConfigs as and when they should be, with new endpoints to serve them (endpoints that will eventually be served by the CDN instead).
[x] RemoteConfig class that generates this config as and when it is needed
[ ] Decide endpoint having an option to use this RemoteConfig instead of the existing team access (with tests to cover it all)
[ ] Saving writes the data to S3 and invalidates the CDN (at least in a flagged way)
[ ] Generates a second file that actually includes the site_apps code to be executed
[ ] Generates a third file that is a personalised array.js loader with all the relevant dependencies preloaded...
[ ] Figure out what to do about the one or two replay things that are "dynamic" (like checking the domain...)
[ ] Cronjob that takes care of ensuring things are in sync (just in case)
[ ] Maybe do this with a hash or something so we can detect whether changes are necessary or not
Problem
WIP - Playing with the idea to see how it works and feels.
See https://github.com/PostHog/product-internal/pull/680 for more info.
Generally the idea is that the new flags service will replace the "decide" django endpoint with a much more scalable solution. The thing it won't do necessarily is handle the "remote config" side of things which is currently the other main use for decide.
My idea is to generate the "config" parts into a dedicated helper model which takes care of creating this config derived from the various settings allowing us to do a few cool things:
Changes
This PR is just part 1 - generate the RemoteConfigs as and when they should be, with new endpoints to serve them (endpoints that will eventually be served by the CDN instead).
👉 Stay up-to-date with PostHog coding conventions for a smoother review.
Does this work well for both Cloud and self-hosted?
How did you test this code?