I have a few other questions maybe you can help me with: • In the sdk there's

gb.loadFeatures({ autoRefresh: true })

: how long it takes to auto-refresh. • There's the GrowthBook proxy application. When it's recomended to use? ( Is there a request number recommendation?) • The Proxy docs says real-time feature rollouts. Without proxy it's not real-time?

Hi Izac, • Auto refresh works with Server Sent Events (SSE) which only work if you're using a Proxied connection (a self-hosted GrowthBook Proxy instance, or soon available without additional infrastructure for all GrowthBook Cloud customers). Enabling auto-refresh with SSE allows us to push real-time (usually <1 sec) updates to subscribed clients. If you've hooked your front-end UI up to these updates, any feature updates will immediately take effect (re-render) on active web browser sessions. This also works in a back-end context (NodeJS), allowing you to respond to changes in real-time in your server code. For both front-end and back-end SSE updates, the local feature cache will also be force updated. • As mentioned, you need to use the GrowthBook Proxy to enable these realtime feature updates. The Proxy handles the SSE updates, as well as provides a caching layer. Cloud customers will soon get all of these Proxy features by default without needing to spin up their own proxy instance. • Without a proxy and SSE, feature changes will take effect on new requests, but may be subject to delays based on SDK-level cache (typically 60 seconds per client). You do have some ability to force refresh cache if desired by using the SDK's

refreshFeatures()

method (you could technically put this on an interval to simulate real-time updates, although it could get expensive based on the interval used).

Thanks for the reply! I'm self-hosting, so I'd like to know if there's a recommendation on request numbers to use the Proxy if the 60 seconds update is not an issue.

Sure if you're not using real-time updates via SSE subscriptions, then you're basically just using a static cache. You can use the Proxy for this (it has options for in memory cache, Redis, Mongo, or hybrid), or you could also skip the Proxy and route the features endpoint through a CDN. Either way will yield better performance and scalability than hitting the GB application directly on each request. As far as how many connections the Proxy will support without SSE, it should be highly scalable although I could not quote an exact number. It's essentially a simple Node/Express application, not too many resource demands outside of proxying your GB endpoint traffic. You'd probably want to use some sort of autoscaling on your proxy cluster (based on CPU and/or memory utilization).