Hi i'm seeing the below docs for golang sdk, I'm going to have lot of requests am I expected to run this for each request assuming I get a different userid in each request? isn't there a single init I call and then polling for update features globally for all features begins in background instead of making the below request for cdn.growthbook.io for each request? I'm aware of the proxy caching but this would add additional complexity looking into a solution that will poll configuration in background without requiring me to install a new service/proxy. https://docs.growthbook.io/lib/go#quick-usage

// Get JSON from GrowthBook and deserialize it into GBFeaturesResponse struct
res, err := http.Get("<https://cdn.growthbook.io/api/features/><environment_key>")
if err != nil {
    fmt.Printf("Error fetching features from GrowthBook: %s \n", err)
    os.Exit(1)
}

var featuresResponse GBFeaturesResponse
err = json.NewDecoder(res.Body).Decode(&featuresResponse)
if err != nil {
    fmt.Printf("Error decoding JSON: %s \n", err)
    os.Exit(1)
}

features := growthbook.ParseFeatureMap(featuresResponse.Features)

Hi there, we had an unsually high number of support requests come through Slack today and are still catching up. We'll look into this on Friday. Thank you for your patience!

The JS/Node SDK has a shared singleton that stores feature definitions and can poll (SSE) for updates; however I don't believe this same construct exists out of the box within our GoLang SDK. Until we have time to build first class support for a shared feature repository, I think you could likely come up with something suitable with some effort. Some ideas, not fully flushed out... • Since you're responsible for your own

http.Get

calls, you could wrap this in a shared service and only update it when you need to. Then you could create single SDK instances per user requests and just tap into that feature repository service. • The Go SDK also supports streaming via SSE (server sent events), which basically handle the scheduled polling for you. You could adapt the strategy above to include a SSE-enabled SDK instance within your shared service and have each user request's private SDK call the shared's

Features()

getter.

Hi, Tomer! I'm the author of the Go SDK. That documentation is a little out of date. (We're in the middle of reviewing some big changes to the SDK that will make it a lot better, and the documentation hasn't kept up with the changes. You can see the details in this PR if you're interested: https://github.com/growthbook/growthbook-golang/pull/13) The Go SDK on pkg.go.dev (v0.1.5) does now have a feature repository that works the same way as the one in the JS SDK. That means that when you've set up your

GrowthBook

instance, you can call the

LoadFeatures

function on it, which starts a background goroutine that receives feature updates over an SSE connection from GrowthBook. Theoretically, you call that once (with the

AutoRefresh

flag) and your features are always up to date with whatever's in the GrowthBook web app. One caveat to that: I've just discovered that there's a bug in the Go SSE package I'm using. It doesn't reconnect properly when the GrowthBook server sends an EOF. I need to fix that, and I'm working on it right now. (This is a common problem with SSE: the server has no timely way of knowing if the client is still there, so it's pretty common to drop the server-side connection and get the client to reconnect. That should normally happen without any trouble, because SSE clients are required to deal with reconnection transparently, but the package I'm using doesn't do it, so I've had to fork it and fix it.)

Perfect!

I released a new version yesterday (v0.1.7) that fixes the SSE reconnection problem. It's up on pkg.go.dev already so you should get it if you upgrade your dependencies.