|
|
|
|
|
|
by btown
592 days ago
|
|
|
One of the first things I look at for products like this is whether the access to a variable's value can be done entirely in memory, rather than requiring a network hop. Varse seems to do the latter: https://github.com/varse-io/varse/blob/master/sdk/varse-io/s... https://docs.statsig.com/client/introduction/ is a good example of the former; each client maintains a data and execution environment that can evaluate getVariable(variable, requestContext) entirely client-side, with full logical consistency across platforms and devices (including stable auto-assignment of user IDs to different segments for A/B tests and canary rollouts), and synchronizes that environment periodically with the server. You can also do this in-house if your configuration model is more complex, with a background thread doing a periodic fetch and setting a pointer to a data structure atomically in memory; we've built a highly custom system for this, with configurability at various levels for our various marketplace participants, with Django and Gevent. As a developer, I don't want to worry about whether I'm accessing a variable in a hot loop and suddenly creating an N+1 request scenario. And not needing to "await" is a huge plus as well. Having a highly granular configuration system that makes each access as quick and simple as an in-memory key-value read is incredibly valuable, and the slight latency in rolling out variable changes until all clients poll for the new values is well worth it. Your approach is still very valid, of course! It's a very reasonable approach for a lot of use cases, and keeps things simple. Excited for your launch and will keep a look out for how the product evolves! |
|
|
One of the features we're excited about adding is a way to cache values locally. Having control of cache ttl and refresh intervals would be a must if we added that. You're right that the tool should just work without the developer worrying about affecting latency.