[HN Gopher] Show HN: Varse - Simple remote application config
___________________________________________________________________
Show HN: Varse - Simple remote application config
Hey HN, We wanted a simple way to update application configs,
without redeploying. We wanted to remotely set variables, and read
them in our application. We created Varse to do this. Varse has a
dashboard for creating key - value pairs and an SDK to read them.
It's un-opinionated and allows for strings, booleans, or even json
objects to be stored. We have instructions for running it
yourself. We also have a hosted version where you can create an
account and manage variables. This is our first time building an
open source project. We'd love feedback on how to do it right.
Github: https://github.com/varse-io/varse Hosted Version:
https://app.varse.io/signup Website: https://www.varse.io/
Contact: izak@varse.io
Author : izakfr
Score : 30 points
Date : 2024-11-05 15:27 UTC (7 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| remram wrote:
| What is a server variable?
| izakfr wrote:
| It's a variable or config that gets injected into a server at
| runtime. At least that's what I've heard it called in the past.
| I think it's interchangeable with environment variable.
| remram wrote:
| Maybe this is the part I misunderstood, what kind of "server"
| are we talking about? I understood it to mean "machine".
|
| If they are trying to say "update application configuration"
| but wrote "update server variable", I urge them to revise
| their marketing ASAP.
| izakfr wrote:
| Yeah that's a good point. We meant application config. I
| will change the repo's description to reflect this.
| izakfr wrote:
| Just updated the repo. Thanks for the clarification.
| xorcist wrote:
| So, configuration?
| zegl wrote:
| Congrats on launching! What's the difference between this and
| Feature Flags in PostHog?
| izakfr wrote:
| 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.
| mdaniel wrote:
| 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...
| izakfr wrote:
| 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.
| senand wrote:
| 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.
| izakfr wrote:
| 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 <= rollout_percent) {
|
| // do gated action and will trigger for 1% of users when
| rollout_percent === 1
|
| }
| robertlagrant wrote:
| 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.
| lux wrote:
| I don't see much mention of secure environment variables. How are
| those treated?
| ibejoeb wrote:
| It looks like this is primarily intended to distribute
| variables to client applications. Secrets are not candidates
| for this kind of distribution.
| btown wrote:
| 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!
| izakfr wrote:
| 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.
| joshstrange wrote:
| 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".
| candiddevmike wrote:
| 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.
| evantbyrne wrote:
| How are key/value pairs encrypted at rest?
| pmdfgy wrote:
| 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.
___________________________________________________________________
(page generated 2024-11-05 23:01 UTC)