fix: bootstrap posthog feature flags #320
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
codeincontext
force-pushed
the
feat/feature-flag-bootstrap
branch
from
6ac8fbf to
4dbe327
Compare
codeincontext
changed the title
Playwright test results
Details
Skipped testsNo persona › tests/auth.test.ts › authenticate through Clerk UI |
|
|
||
| const setKv = async (response: Response) => { | ||
| const value = await response.text(); | ||
| await kv.set(KV_KEY, value, { ex: ONE_MINUTE }); |
There was a problem hiding this comment.
Does this need kv.set<some type>?
There was a problem hiding this comment.
The thing is, I don't know if it matters to us what the shape is if we're just caching it. Posthog's own code that calls fetch doesn't actually put a type on it either, so it could be a bit of extra effort for something that we don't need to validate and could drift from the type
| }; | ||
|
|
||
| const getKv = async () => { | ||
| const value = await kv.get(KV_KEY); |
There was a problem hiding this comment.
And here I think if we use kv.get<some type> we can validate it matches the type? I'm not sure where I saw this, but perhaps look up whether this is possible?
There was a problem hiding this comment.
I did have a look, but I haven't seen it in the docs. I guess for runtime validation it would need to be an argument, and then it could use something like zod. But that could be extra effort for what we actually need
| }; | ||
|
|
||
| export const featureFlagsPollingInterval = | ||
| process.env.NODE_ENV === "production" |
There was a problem hiding this comment.
Another candidate for a isEnvironment helper?
There was a problem hiding this comment.
Possibly, though I wonder if we could get a similar result if we have stricter types on the env vars
| } from "./featureFlagEvaluation"; | ||
|
|
||
| const host = process.env.NEXT_PUBLIC_POSTHOG_HOST as string; | ||
| const apiKey = process.env.NEXT_PUBLIC_POSTHOG_API_KEY || "*"; |
There was a problem hiding this comment.
I usually do too, but I wonder if there's a greater chance of an empty string on an environment variable?
codeincontext
force-pushed
the
feat/feature-flag-bootstrap
branch
from
b62f637 to
d7cfd6f
Compare
codeincontext
force-pushed
the
feat/feature-flag-bootstrap
branch
from
d7cfd6f to
8934bf0
Compare
codeincontext
force-pushed
the
feat/feature-flag-bootstrap
branch
from
8934bf0 to
95daeef
Compare
codeincontext
force-pushed
the
feat/feature-flag-bootstrap
branch
from
95daeef to
90a0617
Compare
|
|
🎉 This PR is included in version 1.14.0 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
We use posthog to set feature flags
We can use feature flags for:
Problem
When we tried a feature flag for download-all, we found that they weren't working if you hadn't given cookie consent. I spoke to posthog and they said that feature flags should work with
opt_out_capturingenabled. It sounds like a quirk of the way we're interacting with the consent bannerSolution
The most robust way to load flags from posthog is to bootstrap them from the server. Then they will be immediately available on the frontend rather than relying on a frontend call
We don't really want to delay page load with the posthog call. We could cache it in KV for X hours, but then we would need to clear the cache when toggling a flag. Another option is local flag evaluation
With local flag evaluation, the posthog client periodically fetches the definitions for the flags, and will evaluate them for each user on the server. Because we're using edge functions, we need to cache those definitions so I've created a fetch client to handle that
If we also want to bootstrap flags that look at properties like the user's email address then we will need a follow up to make that available when we bootstrap. I have ideas for that, but one step at a time...