Client-side PostHog libraries (like posthog-js
) are able to have a rather simple feature flags implementation, given that they only ever have to deal with one user. As such, we can make a request at the start of a session to fetch feature flags that are enabled for a user, keep those on memory, and periodically check for updates.
On server-side libraries, however, we need to be able to handle n distinct IDs. As such, we are unable to fetch user-specific flags proactively, since there is an infinite number of possible distinct IDs that one can call isFeatureEnabled
with. As a result, we've developed an approach to implementing feature flags on our server-side libraries, described in this doc.
A note: simple flags
To improve performance of feature flag methods on the server, all PostHog feature flags have a property is_simple_flag
. A simple flag is one that does not rely on any filters, so calculating if it is on for a given user or not depends entirely on two things: rollout percentage and user distinct ID.
Distinct ID is passed in by the user, so all we need is the rollout percentage to determine if a flag is on without having to offload the calculation to the PostHog instance.
Pseudocode Implementation
Ensuring consistency with isSimpleFlagEnabled
To check if your isSimpleFlag
implementation is in accordance with others, the following should be true:
SHA1('a.b')
should equal'69f6642c9d71b463485b4faf4e989dc3fe77a8c6'
- The floating point value for the hash of
'a.b'
should equal0.4139158829615955