Turbo mode for server-side feature flags

[macobo]

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.

1. Cache (and periodically) update feature flag definitions in client libraries
2. Extend the amount of flags that can be evaluated on client-side

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!

[macobo]

Some notes from performance on our (/decide and event-ingestion side): #7150

Aside: The /decide API does (I think) 2-4 extra sequential SQL queries now every time for the overrides. Given how performance-critical the endpoint is (can lead to data loss) this might cause us trouble down the line 😅 A naive fix here might also bring down event ingestion in a similar way.

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.

[paolodamico]

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:

• Running an A/B test for 50% of users within the US.
• Running an A/B/C test for 33% of users on Chrome.
• Running an A/B test for 50% of "companies" (a group) with a property "enterprise".

[macobo]

A related use case/opportunity: leveraging feature flags internally in ingestion and doing staged deploys.

Cc @tiina303 @fuziontech @timgl @yakkomajuri

[macobo]

Related usecase: calling .identify with new person props followed by isFeatureEnabled will return misleading results this feature could avoid

[rcmarron]

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:

• Call .identify()
• Wait for onFeatureFlags()
• Then render the page

They are concerned about the delay between .identify() and onFeatureFlags() and concerned that the results might not be immediately accurate.

A few notable aspects:

• In their minds, they were defining a cohort for their different programs and then using those cohorts in the FF
• While timing was a concern, it sounded like it was more of a "this can't take a second" concern and less of a "how many milliseconds" concern
• They alluded to a client side solution like the one described here as being ideal for them.

[rcmarron]

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 /home happens right away).

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 /home logic happens before we wait for these feature flags. And restructuring it is a pain. Ideally, we wouldn't have to worry about this, and as users of feature flags, it would "just work".

It seems allowing the client to run local feature flag logic synchronously would solve it. The flow would be:

• An end-user loads a posthog page
• Logic for that projects feature flags are fetched + cached
• User logs in and .identify() is called.
• User's properties from .identify() are compared against FF logic fetched above
• Feature flags are set synchronously without a server call

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)

[mariusandra]

One user recently complained about this. It takes a very long time (one e2e ingesting roundtrip) before /decide returns meaningful data for feature flags that depend on user or event properties. This is made worse if the flag depends on cohorts.

We need to improve this flow significantly, and in a way that doesn't hit clickhouse whenever possible. Tagging @neilkakkar as feature owner :).

[neilkakkar]

Our spec for making this happen:

#10459 (comment)

[neilkakkar]

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

1. Python - @neilkakkar
2. Go - @EDsCODE
3. Ruby - @neilkakkar
4. Node - @liyiy
5. PHP -

[neilkakkar]

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)