I recently created a growthbook proxy for work.
I believe this would have helped everyone not just us.
Having a proxy, which updates list of features based on webhook events sent by growthbook instead of things being polled from individual services would probably help growthbook keep it's CDN fees a little down.
Basically my idea is to have a proxy kinda thing, which listens to webhook events AND has a polling duration. On top of that, it also accepts the growthbook API Key as environment variable and make sure it contains the latest set of features.
This helps growthbook.io keep it's CDN fees a little down hopefully. And individual businesses wouldn't have to hardcode their API Keys in the clients or individual services every time.
Is this something growthbook team would be interested in? 🙂
Since I've done this before, I should be able to contribute to this in almost 2 days, only thing new for me would be to have the webhook part (I wouldn't apply the change, rather when I receive the webhook, I'd ask for the latest features) 🙂 (only complication is that maybe CDN won't let me reach growthbook API just yet, unless you guys are invalidating that somehow)
I understand it might be some undertaking, we can have a discussion first 🙂
08/13/2022, 11:50 AM
Hi Nishchal, I think that would be useful to others. We've talked about building something similar ourselves. There are some additional things we were thinking of adding to the proxy server eventually such as websocket support (so clients can get feature updates streamed to them), and server-side evaluation of feature flags (so rules don't have to be exposed to the front-end).
Happy to collaborate on this, or if you want to build a V1 quickly yourself, we can figure out later how we can extend it.
08/13/2022, 11:54 AM
we can follow the scooter analogy,
We start with v1 with simple service which acts as a proxy,
we can do a new feature release with websocket for people who want it 🙂 while maintaining backwards compatibility.
although for the proxy to evaluate server side, I hated the amplitude because it'd mean so much of talking to experiment-service per request, that it won't be ideal
We'd have to think about things like error handling, latency, timeouts, circuit breaking etc, I don't think having SSR evaluation is a good idea.
The current implementation of what we want, there's absolutely 0 chance of anything going wrong 🙂 because everything is local evaluation.
web socket to listen to changes is actually a good idea 🙂
we can certainly give options for other people to decide for themselves, it'd help generate clients for languages which we don't support yet 🙂
08/13/2022, 12:12 PM
Yeah, agreed. I think SSR evaluation is useful for certain situations so it's a good option to have, but I definitely wouldn't make it mandatory.
08/13/2022, 12:25 PM
do you have a place where I can add a design document or something?