Settings Management

As we have already said, all settings parameters are defined in .yaml files(s). How to organize these parameters is up to us. We can set all of them in a single file (best way for small applications) or split them in multiple files or even folders.

The only important thing is to tell Kalgan the path of the file or folder where our settings parameters are. We have to do this in the main.rs of our application and pass this path as the first parameter in function kalgan::run. By convention it's recommended to locate our settings parameters in the folder config/app/:

...
fn main() {
    kalgan::run("config/app", controller::resolver, None);
}

However this is just a convention, fell free to locate your settings up to your needs.

Application Static Data

Keep in mind that we can use this path to locate any other static data that should not be in a database but in the application file system. Again, by convention we recomended to keep this data away from the settings paratemers, for example in a different file:

project/
    ...
    config/
        app/
            settings.yaml
            data.yaml
...

The discussion whether a data set should be in a database or in the file system is out of the sope of these docs.

Settings Access

The first action Kalgan executes, even before the startup of the server, is to parse all the configuration files and create a std::collections::HashMap with all these parameters. Thanks to crate lazy_static this Hashmap can be access from any place in our application.

We have a few built-in functions in kalgan/src/settings.rs to retrieve the values of this collection, which basically are a wrapper for serde_yaml::Value functions:

Regarding the syntax, these parameters must fulfil YAML rules and one more thing: the use of dots in the key name is forbidden. As a workaround we can use hyphen instead or a colon followed by a line break and indent.

Notice that access is based on dot notation. For example:

familiy:
    father:
        name: "Foo Bar"

Which can be retrieved as follows:

...
let father_name: String = kalgan::settings::get_string("family.father.name").unwrap(); // "Foo Bar"
...

Settings Reload

While developing it's annoying to stop and rebuild the app to test every little change we make. Sometimes there's no other way, for example, when we change our controllers, middlewares, services... that is to say, Rust code.

But we can prevent this situation when working with non-rust code: templates, statics and .yaml files. This means that every time we refresh the browser we can see the changes we make in these files on the fly. This feature is extremely powerful but it has a couple of caveats:

• Performance: reloading all these files in every request impacts on the response time of our app. Keep in mind that the browser usually sends not only one but multiple requests on the background (as minimum, one for each static file).
• Console output: while this feature is extremely useful to test our changes, having all these processes being trigger in every request the console output gets pretty overloaded.

To coupe with these downsides we can count with 2 settings parameters:

Notice that refresh_config_timeout only works when is_prod is false and as soon as the latter is set to true we'll have to restart our app to reverse this settings.

Settings Table

Find below the table with all the settings parameters available: