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

21–25 of 25 posts

Re: Show HN: Varse – Simple remote application config

#21

Post by joshstrange »

izakfr wrote: post #19
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.

I’m sure you are already considering this but you’ll probably want the ability to “background” update the local cache so that you don’t have a request hang randomly every X minutes. Also might be nice to specify “I’m ok with a potentially old cache value” on a per-key basis. In my case I think I’d always be fine with “if you can’t reach the config server just use what you last got”.

Re: Show HN: Varse – Simple remote application config

#23

Post by pmdfgy »

Congrats on launching. Looks very clean.

The main problems I have with these kind of solutions are :

- 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

- 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

- 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

The usual combo "Environment Variable / Restart" proposed by most PaaS offerings will be hard to fight IMO.

In any case, good luck with this project.

Re: Show HN: Varse – Simple remote application config

#24

Post by yoz »

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 especially good is with targeting rules, but more on that later.

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].

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.

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.

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.

[1] https://github.com/andrewdmaclean/awesome-feature-flag-manag...

[2] https://www.growthbook.io/

Re: Show HN: Varse – Simple remote application config

#25

Post by navs »

izakfr wrote: post #8
zegl wrote: post #3

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. Have you used Feature Flags in the past? I'm curious what your experience was.

I use posthog for remote config. Basically long lived flags containing a json payload that allows me to target consumers based on specific properties of that consumer.
Post reply on HN