Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: Varse – Simple remote application config

github.com

Post reply on HN
Print view View original

11–20 of 25 posts

Re: Show HN: Varse – Simple remote application config

#11

Post by mdaniel »

You'll want to start by not using string interpolation when you meant to use encodeURIComponent https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cf... 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" https://axios-http.com/docs/req_config

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 https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cf... but hey, maybe the first chapter is actually a legitimate key name for all I know https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cf...

Re: Show HN: Varse – Simple remote application config

#12

Post by izakfr »

mdaniel wrote: post #11

You'll want to start by not using string interpolation when you meant to use encodeURIComponent https://github.com/varse-io/varse/blob/c14e3427138d6e70f49cf... 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" https://axios-http.com/docs/req_config Because the unwritten rule of any API is that surely as you always use "foo" so…

The axios point is helpful, thank you for mentioning it. I'll make a bug ticket to fix.

Also, we should probably put restrictions the keyname scheme. Ideally, it should be something readable.

Re: Show HN: Varse – Simple remote application config

#13

Post by senand »

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 https://martinfowler.com/bliki/CanaryRelease.html)?

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.

Re: Show HN: Varse – Simple remote application config

#14

Post by izakfr »

senand wrote: post #13

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 https://martinfowler.com/bliki/CanaryRelease.html )? 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.

You could make a variable like `rollout_percent` that is an number. It could be set to 1. Then in your app you could do something like:

const rollout_percent = await varse_client.getNumber('rollout_percent');

const random_number = Math.random() * 100;

if (random_number // do gated action and will trigger for 1% of users when rollout_percent === 1

}

Re: Show HN: Varse – Simple remote application config

#16

Post by btown »

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!

Re: Show HN: Varse – Simple remote application config

#17

Post by robertlagrant »

izakfr wrote: post #14
senand wrote: post #13

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 https://martinfowler.com/bliki/CanaryRelease.html )? 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.

You could make a variable like `rollout_percent` that is an number. It could be set to 1. Then in your app you could do something like: const rollout_percent = await varse_client.getNumber('rollout_percent'); const random_number = Math.random() * 100; if (random_number // do gated action and will trigger for 1% of users when rollout_percent === 1 }

That's true, although it might get complicated to remember the setting for each user, and for each rollout feature! For more complicated combinations you need groups on the configuration side and to put users (or buckets of users) in groups and give those groups a certain config option.

Re: Show HN: Varse – Simple remote application config

#18

Post by candiddevmike »

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.

Re: Show HN: Varse – Simple remote application config

#19

Post by izakfr »

btown wrote: post #16

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 getV…

Thank you for the feedback, this is helpful!

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.

Post reply on HN