ConfigurationStore is not public

[leodurazoreverb]

Hello eppo-team!

The ConfigurationStore class has a public initializer and additional functions; however, its 'internal' protection level makes it inaccessible. Therefore, how can I retrieve the Configuration?

[leoromanovsky]

@leodurazoreverb Thanks for the question - could you help us understand the priority of this request by describing what the underlying Configuration will be used for? Are you needing it for debugging?

[leodurazoreverb]

We want to use the last fetched configuration for the app. If the client updates the experiments, that will update the current configuration and change the current client, and we want to maintain only one configuration per session when the app starts. For this reason, we would like to keep the previous fetched configuration when the app starts.

• Launch the app and retrieve the experiments. Cache the configuration as is currently done.
• In this session, utilize the experiments retrieved during the previous app launch.
• On the next app launch, activate the experiments that were fetched during the previous session.

[leoromanovsky]

Thanks for explaining that - yes certainly understand that sentiment. This is currently possible with our JS SDK with certain initialization parameters: https://docs.geteppo.com/sdks/client-sdks/javascript/Initialization/

• All evaluation happens from memory but we control how that memory store gets bootstrapped.
• On browser load the configuration is loaded in the background. The in-memory cache is bootstrapped from localStorage (last session values). When configuration finishes loading it is written to localStorage so it can be bootstrapped into memory on the next session.

For experiment coherence it is critical that a user is only exposed to a single experiment variation; as you mentioned a configuration should not change within a session.

You feel you can accomplish your goals if a configuration export method was available? Ideally the the JS SDK functionality is something we could develop and surface do you via parameters but the former could be a quick way to get what you need.

[leodurazoreverb]

Yes, having the ability to export the configuration is essential. This feature would allow us to initialize offline and control where the updated configuration is saved for future sessions. However, I believe this process should be better managed by the SDK on your side, similar to how the JavaScript SDK functions. This approach would prevent the load function from overriding the current client, ensuring that the client consistently operates with the configuration it was initialized with.