Frequently Asked Questions

Date of slack thread: 5/29/24

Anonymous: Hey team, question for you about the result of getClientInitializeResponse and piping that through to the react sdk. My team has been debugging some initial page load slowness and someone flagged that the resulting payload that comes back from getClientInitializeResponse is very very large. We have a lot of feature gates and dynamic configs so it’s not surprising that the evaluation results for a given user is large but I am curious if there are some ways to mitigate.

The most obvious thing that comes to mind is that we barely actually use any dynamic configs on the client side. We generally just use that feature on the server side. It would be ideal if we could denote which gates/configs are relevant for client sdks and have getClientInitializeResponse just pass us those instead of all flags. Assuming that isn’t a quick thing to do on your end, any other suggestions here?

Cooper Reid (Statsig): Which SDK is this? You can manage overall config size using a few different approaches which may help reduce latency associated with their method:

1. https://docs.statsig.com/guides/using-environments#environment-specific-sdk-keys will allow you to control which gates/tests get downloaded by the SDK and persisted to Data Store. If you create a Gate that targets only “development”, the production-SDK key won’t download that gate.
2. You can also consider using https://docs.statsig.com/sdk-keys/target-apps to target specific gates/tests by experiment key to keep the config size leaner.

Anonymous: We’re using the nodejs sdk on the backend and react sdk on the client

Anonymous: Target apps looks exactly like what we want. Thank you!

Anonymous: Hey all! As part of this work, I was hoping you might have some pointers on how to convert Statsig IDs back to their names. I’m trying to get a list of stale gates we can clean up, but I’m stuck on how to get our names out of an ID like this: DgM1zPA/TAsyalQaED1C/wvSMtIia/g9fdKBlcTqE50=