chore(flags): use the new /flags endpoint to manage flag evaluation for team 2
#1841
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
There was a problem hiding this comment.
PR Summary
This PR introduces a new /flags endpoint specifically for PostHog team 2's feature flag evaluation, while maintaining the existing /decide endpoint for other customers.
- Added
DEFAULT_POSTHOG_APP_API_KEYconstant to identify PostHog team 2 requests in/src/constants.ts - Modified feature flag evaluation in
/src/posthog-featureflags.tsto use/flags?v=2endpoint when token matches team 2's API key and remote config is enabled - Added logic to handle remote config interaction, ensuring
/decideendpoint is still called when needed for non-flag functionality - Added eligibility check
eligibleForFlagsV2to determine when to use the new endpoint
2 file(s) reviewed, no comment(s)
Edit PR Review Bot Settings | Greptile
|
Size Change: +1.31 kB (+0.04%) Total Size: 3.63 MB
ℹ️ View Unchanged
|
src/posthog-featureflags.ts
Outdated
| @@ -390,10 +391,12 @@ export class PostHogFeatureFlags { | |||
| data.disable_flags = true | |||
| } | |||
|
|
|||
| const eligibleForFlagsV2 = token === DEFAULT_POSTHOG_APP_API_KEY && this.instance.config.__preview_remote_config | |||
There was a problem hiding this comment.
Any chance we could just do
| const eligibleForFlagsV2 = token === DEFAULT_POSTHOG_APP_API_KEY && this.instance.config.__preview_remote_config | |
| const eligibleForFlagsV2 = this.instance.config.__preview_flags_v2 |
so that I can run this on localhost easily?
There was a problem hiding this comment.
oh yeah, and then we can just set the preview to true for our own posthog JS initialization + any other instances of it.
That's a good idea; I might still want to use API tokens down the road (especially when rolling out to specific users), but I'm happy doing something like this instead. Thanks for the suggestion!
There was a problem hiding this comment.
@robbie-c went ahead and went with the config-based approach, although I might need to use API tokens down the road too (so I can turn this on for specific customers as needed). I think my plan will be to have a set of tokens that have this feature toggled on, and then allow folks to specify it in their config as well.
Changes
Basically, what I'm doing is that any request with the PostHog team 2 public API key, we use
/flags, and then for everything else we just use/decide.There's a little bit of trickiness w.r.t remote config (I added a comment to that end) since new flags relies on the fact that remote config takes care of all the other non-flag-related code (it basically does away with
/decidealtogether). But if a customer isn't using remote config, they'll need to hit/decideanyway. I should have this handled in the logic, but worth calling out.