Introduction

When building software application it is a common practice to design it in such a way, that many aspects of its behavior can be changed by various inputs such as program parameters, OS environment variables, system properties as well as configuration provided in various files or even databases. If we're talking about Java world (and we are, since at least now nifty-settings is a purely Java library), more often then not changes in these inputs require application restart in order to be applied. For many applications this can be perfectly fine. If changes to configuration are rare and, say, application is designed using the recently so popular microservices architecture and deployed with a container orchestration, this might not cause any noticeable effect for the end user.

In some cases, however, such an approach might not be viable. For example, for high-load / low latency applications that rely significantly on memory caches or require significant "warm-up" times until JIT compiler does its job, too many restarts might not be desirable as they affect performance.

Another case is for large applications having huge user base and constantly going through lots of changes - you might be unable to afford changing functionality willy-nilly, but rather have to take more careful or even scientific approach - rolling out every change incrementally, doing A/B testing, gathering statistics and doing in-depth analysis of the impact etc. In such a scenario again it could be more practical to make your program contain both versions of the code - before and after the change, and then enable the new functionality gradually based on which user is triggering it or utilizing some probability or whatever:

if (functionalityEnabledNowForThisUser) {
    newImplementation();
} else {
    oldImplementation();
}

Again - there is a need for configuration, that can be changed on-fly continuously and that does not require writing a lots of boilerplate code to achieve this.

In Java there is actually a built-in technology for doing just that - Java Management Extensions (JMX). It allows you to expose various properties of objects and also to call setters on them. Trouble is, it is scoped to a single application runtime. If you have a cluster of peer application instances, it is up to you to keep track of them and invoke setters on every instance. So, JMX essentially requires a push model to be implemented.

flowchart LR
    SRC[Configuration]
    SRC -->|Push| A(Instance 1)
    SRC -->|Push| B(Instance 2)
    SRC -->|Push| C(Instance 3)

Loading

Arguably, for large clusters pull model seems to be more straight-forward, reliable and easier to implement - every instance of your application upon startup would connect to some central configuration service and ask for its configuration. For getting configuration changes it would either do regular polling or establish a two way communication, that's irrelevant, but anyway, you don't need an orchestrator keeping track of all the instances, if the initial action comes from the configuration client - your application.

flowchart LR
    SRC[Configuration]
    A(Instance 1) -->|Pull & Subscribe| SRC
    B(Instance 2) -->|Pull & Subscribe| SRC
    C(Instance 3) -->|Pull & Subscribe| SRC

Loading

NiftySettings is a library (or, potentially, a collection of libraries) that aims at providing a convenient way to configure your application. If it ever will get this far, it could also integrate seamlessly with existing technologies such as JMX, Spring Framework / Spring Boot. It could support delivering configuration settings from various sources, such as Git repositories, databases or other storages.

A note on the naming - word "configuration" is used quite a lot in different contexts. In Java world, where Spring Framework is very popular, it will often refer to Spring Context Configuration (which is the way your Spring beans are created and wired up with each other). Term "property" again is used in many different scenarios (say, java.util.Properties., Spring Boot's application.properties etc). It seems on other hand, that word "settings" is quite uncommon and at the same time describes perfectly configuration properties, that could be "lighter", could be changed on-fly, without destroying and recreating all the objects.