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.<p>Varse seems to do the latter: <a href="https://github.com/varse-io/varse/blob/master/sdk/varse-io/src/client.ts#L18">https://github.com/varse-io/varse/blob/master/sdk/varse-io/s...</a><p><a href="https://docs.statsig.com/client/introduction/" rel="nofollow">https://docs.statsig.com/client/introduction/</a> 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.<p>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.<p>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!
Thank you for the feedback, this is helpful!<p>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.
You'll want to start by not using <i>string interpolation</i> when you meant to use encodeURIComponent <a href="https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cfabf78bd9c53e87ac5dc/sdk/varse-io/src/client.ts#L18">https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cf...</a> They should be ashamed of their docs that don't specify whether axios.get does URL encoding for the user or not, but my strong guess is "not" <a href="https://axios-http.com/docs/req_config" rel="nofollow">https://axios-http.com/docs/req_config</a><p>Because the unwritten rule of any API is that surely as you always use "foo" someone will want to put the first chapter of War and Peace. If nothing else, some validation for what a variableId can look like would also help consumers not have to read external documentation to know if it's [a-zA-Z0-9] or what. Even the server-side of it isn't illustrative <a href="https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cfabf78bd9c53e87ac5dc/server/src/api/variable.ts#L16">https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cf...</a> but hey, maybe the first chapter is actually a legitimate key name for all I know <a href="https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cfabf78bd9c53e87ac5dc/server/prisma/schema.prisma#L60">https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cf...</a>
The axios point is helpful, thank you for mentioning it. I'll make a bug ticket to fix.<p>Also, we should probably put restrictions the keyname scheme. Ideally, it should be something readable.
I like the simplicity. However, it is possible to rollout a feature flag only to a part of the user, e.g. a 1% canary release (cf <a href="https://martinfowler.com/bliki/CanaryRelease.html" rel="nofollow">https://martinfowler.com/bliki/CanaryRelease.html</a>)?<p>If not, I'm not sure this brings more to the table than simple configuration changes that are rolled out through your next deployment, which should be frequent anyway, assuming you have continuous delivery.
I don't see much mention of secure environment variables. How are those treated?
How are key/value pairs encrypted at rest?
Congrats on launching. Looks very clean.<p>The main problems I have with these kind of solutions are :<p>- Having to make an HTTP request to get a variable (or multiple ?) for my local function to do its job. And that's a clear no-go for me, in terms of latency<p>- Having variables stored "somewhere else" complexifies the rollout of new features introducing new "variables", as one needs to update the external tool (here Varse), to create this variable<p>- Overtime, you end up with a big bag of obsolete variables that are not used anymore by the main application because you forget to remove them<p>The usual combo "Environment Variable / Restart" proposed by most PaaS offerings will be hard to fight IMO.<p>In any case, good luck with this project.
Since others have mentioned them already: yes, this is what feature flag systems are for. They're not just for rollouts and experiments, though they're good at that too. Where they're <i>especially</i> good is with targeting rules, but more on that later.<p>There are already several good open source and commercial flag systems[1], some of which have SDKs for many different server-side and client-side languages, e.g. Growthbook[2].<p>At its most basic, a feature flag client SDK lets you evaluate a variable instantly, without blocking/async, because the variable was already fetched and cached when your app started up. The SDK also maintains an ongoing background mechanism of some kind to keep that cache updated with changes from the server; the most popular method is polling (i.e. re-fetch the variables every X seconds) but a more effective way is to keep a single long-lived HTTP connection open to the server and listen for Server-Sent Events. The SDK should also, ideally, emit in-app events whenever changes arrive.<p>Targeting rules are what make feature flags much more useful: they allow you to define logic that changes the evaluation of a flag depending on context. For example: enabling new features or new code versions depending on who the current user is, or which server is handling the request, or the current time of day. Sure, this is all logic you could do in code, but then every change to that logic requires an update and restart. Having the logic stored and communicated with the flag gives you a separate level of control that's much easier and faster to change.<p>So yeah, what you're doing here is creating yet another feature flag system. Even if you're saying "but this is meant for simpler stuff" I would honestly just go with an existing, somewhat mature system like Posthog or Growthbook than invest any more engineering time in this, unless you have major use cases in mind that they don't support - and even then, I would be careful. Simplicity alone does not give you any real advantage that is worth the effort.<p>[1] <a href="https://github.com/andrewdmaclean/awesome-feature-flag-management">https://github.com/andrewdmaclean/awesome-feature-flag-manag...</a><p>[2] <a href="https://www.growthbook.io/">https://www.growthbook.io/</a>
What is a server variable?
Congrats on launching! What’s the difference between this and Feature Flags in PostHog?
Feature Flags looks like it's crafted around automated rollouts. Varse was designed to be more manual, just for reading / writing key - value pairs. You can use it to store long-lived variables like database_url. It could also be used for short lived variables like percent_db_migration_rollout.<p>Have you used Feature Flags in the past? I'm curious what your experience was.
I thought this was a joke project TBH. This use case is satisfied by so many products out there that I struggle to see how this differentiates from any general purpose KV or database, not even considering more purpose built services like Etcd or Consul. Maybe the SDK? But there are plenty of hot reloading SDKs that are vendor agnostic.