-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Turbo mode for server-side feature flags #7115
Comments
Some notes from performance on our (/decide and event-ingestion side): #7150
We've been adding cruft (variants, overrides) to feature flags at various layers that makes feature flags more expensive to compute for us. We should clean this up alongside client-side performance issues if we go there. |
In terms of experimentation, I think we'll want to accomplish the same thing as for feature flags, loading the flags as quickly as possible. Experiments could involve experiences from the very first touch point in the app. We could even consider a class of experiment where the user is immediately taken to a different page on load. For example: you're trying out a new landing page, you'd want to redirect the user as soon as they open your app. We would also need to scope down better the problem sets we want to address with Experimentation, but the way we "allocate" users to a feature flag may change. Some examples we could potentially solve for:
|
A related use case/opportunity: leveraging feature flags internally in ingestion and doing staged deploys. |
Related usecase: calling .identify with new person props followed by isFeatureEnabled will return misleading results this feature could avoid |
Had a call with a customer that was concerned about this exact thing. They have users that belong to different programs (identifiable with a person property), and they want to use feature flags as soon as the user logs in. Basically, their flow is:
They are concerned about the delay between A few notable aspects:
|
Adding some context for a use case I just hit dog-fooding feature flags. I was just adding a new Project Homepage feature, and I wanted to put it behind a feature flag to run an experiment on it. The issue was that this feature flag needs to be set as soon as a user logs in (because the redirect to Right now, we have logic to try to wait for feature flags to respond before rendering the app (with a timeout), but the way our app is structured, the re-direct to It seems allowing the client to run local feature flag logic synchronously would solve it. The flow would be:
There is still an issue for users landing on a page for the very first time and need feature flags right away, but that seems like a less frequent case. (cc @neilkakkar as feature owner) |
One user recently complained about this. It takes a very long time (one e2e ingesting roundtrip) before We need to improve this flow significantly, and in a way that doesn't hit clickhouse whenever possible. Tagging @neilkakkar as feature owner :). |
Our spec for making this happen: |
Also, to manage work, please put your name against whichever library you pick up. I can probs pick up one or two more: cc: @EDsCODE @liyiy @alexkim205
|
Server-side evaluation is done. Here's relevant docs: https://posthog.com/docs/integrate/server/python#local-evaluation For the problems around instantly having flags available, we now have bootstrapping flags: https://posthog.com/docs/integrate/client/js#bootstrapping-flags (which also leverage server-side evaluation to get flags to the client quickly) |
Is your feature request related to a problem?
Currently checking a feature flag in client libraries other than posthog-js can result in up to 2 network requests to our servers.
This is not ideal for our users - it slows down their render times and adds load on us.
Describe the solution you'd like
Mechanisms for minimizing network requests.
Currently on the client we evaluate the flag if it's a simple percentage and all flags that use property/cohort/group property lookups end up querying our servers. However properties are almost always provided by the exact same app that's using feature flags already.
I suggest to add optional arguments to indicate properties/cohort status for an user when checking if a feature flag matches the user. If they are provided we are able to evaluate the flag on the client in more cases.
Describe alternatives you've considered
...
Additional context
cc @paolodamico - food for thought regarding experimentation as well.
Thank you for your feature request – we love each and every one!
The text was updated successfully, but these errors were encountered: