https://www.growthbook.io/ logo
Join Slack
Powered by
hi, is there a way for me to access the bootstrapp...
# ask-questions
r
hi, is there a way for me to access the bootstrapped frontend SDK thingy easily when using the fastly edge app? i need to use the manual approach, but i want to leverage that feature if possible. so far the only idea i have is to copy/paste the entire injectScript() method into my app
on the note of edge stuff, is there a growthbook client format way to pass experiments? i currently msgpack the client payload as chunked headers to origin, but it doesn't contain experiments, is that correct or am i missing something? i get all features, but only 
experiments: []
or that only is for whatever manual experiments the client was initialized with, is it so that the features and default values received represent the experiment values for the user i initialized growthbook for? ie can i use those flags serverside and not expect a different result when the gb client initializes in the browser?
given all attributes are identical in edge and browser i mean
h
The injected SDK is available globally via 
window._growthbook
. You can also access the injected payload directly (feature & experiment definitions), which would be in 
window.growthbook_config.payload
. If you want to customize how things are injected, you can use lifecycle hooks to write the growthbook object or its dependences as you see fit.
For you second question, I'm not sure I fully understand. In the SDK payload 
experiments: []
represents what we call "auto-experiments", which are experiments that can automatically run and have no feature flag attached, such as a URL Redirect or Visual Experiment. All other experiments will be embedded in the rules section of each feature in the 
features: {}
part of the payload. As long as your user attributes are stable between frontend and backend (specifically your hash attribute, such as 
id
), bucketing will be deterministic.
r
your final sentence was what i reached just a while ago, i was too afraid to send the id for the visitor used in edge to origin and have it be cached in the html, but i understand as long as i make a cache key of the gb payload and not the attributes, it will yield the same result even if client-side is initialized with an id from document.cookie, possibly replacing the one served in cached HTML
h
are you talking about page cache or payload cache? If the former, you do need to be careful not to cache whatever the edge injects onto the DOM (user attributes, deferred tracking calls, etc)
r
yes, indeed. i resolve the payload in fastly compute edge and pass it via http headers to origin, so i can do both the serverside and client side flagging i need to do, and i vary on the payload header
if i don't have an id serverside that matches the bucketing clientside, i will most definitely get hydration issues, so i just need an id that represents getting bucketed the same way as another one which gets served cache for the same gb payload
or am i missing something here?
h
Are you doing edge-side tracking or deferred client-side tracking? If edge, then some of the cache key issues disappear. If deferred, then you need to take care to not cache any of the deferred tracking calls. And in either case, it's probably best not to cache any injected user attributes. Pre-computing possible permutations on edge is tricky. It's not something we build the Edge SDKs to accommodate, so you'll probably need to do a fair amount of your own stitching to suit your needs.
r
yeah i built my own thing with your normal sdk before you released the edge ones. currently i'm using your kvstore approach for cache, but the rest is custom. i don't use any edge tracking of deferred calls, i pass all edge attributes (including id, which gets cached) and payload. then i init the client client-side with the correct ID spread on the attributes from edge, and initSync with the payload from edge. then i just use the normal client side trackingCallback
i see no other way to have experiments running serverside and client side while caching HTML of the unique combinations of flags and experiments in CDN
h
If you happen to be using Next.js under the hood, they have a similar recommended approach using middleware and experiment-specific headers but they provide more batteries. They have a flags SDK, for which GrowthBook has an official adapter. Probably not applicable in your case, but might be worth checking out for inspiration.
r
actually using remix under the hood, but i did see that flags sdk for next
11 Views
Open in Slack
PreviousNext
Powered by