Configuration Files are Bad
Consider this web site. There are lots of configurable items. Here's just two configurable items :
- Which pages are password protected.
- The logging level (should we log only errors, warnings, or also include information messages too).
We could store this information in a configuration file, which is parsed when the web server is started.This is the "normal" thing to do, and I think it is wrong.
Firstly, I think we should recognise that these are two very different kinds of configuration.
Type (1) never changes during the running program. From the program's point of view, it is immutable (read-only).
Type (2) can change without restarting the program. It is mutable (read and write).
IMHO, it makes no sense to put mutable data into a configuration file, we have a better thing for this, it's called a database! Anything that we *expect* to change, we should create unit tests for. Does changing the logging level do what we expect? If it passes our QA, then we can feel safe changing it in a live running program.
Our unit tests do not need to test for all possible values for type (1) data. They only have to test for the one and only value. If we need to add a new page to those that are password protected, then write a new test script, test it, and push the new version of the application.
So changing type (1) requires us to go through the QA process again. Type (2) should already be covered by our unit tests.
Where Should We Store Configurations?
For type (2) mutable data, why not use a database? That's what databases are for! A configuration file is not designed to be written to, only read.
For type (1) (immutable data), we have choices.
We could use a traditional conifigutation file with its own syntax, and therefore a parser. We should document the file's format, and allowable values etc.
That's a lot of work, and I believe there is a much better place... Your application's source code.
There is no extra parser, no extra documentation (above the documentation for the application started API).
There's also other advantages :
- The configuration cannot have syntax errors, because it is compiled.
- It cannot use out-dated options (because it is compiled, and outdated methods will no longer exist).
- We get warnings when we use deprecated methods, and therefore we can transition to new versions more easily.
- Your program, and your configuration file now use the same syntax (and the same language).
But isn't hard coding bad?
Well, yes. If you hard code a value deep down in a low level function somewhere, that is bad.
But I'm "hard-coding" all the values into the application "main" method (or the equivalent for a web application).
Either we don't call this hard coding, or we should accept that this kind of hard coding is ok.
The Down Sides
We need to recompile the application to change a configuration.
I suggest that this is a feature, not a problem. If we want to change the behaviour of the production system, then we should damn well go through a rigorous procedure. We shouldn't be allowed to tinker on a whim.
The Bigger Picture
Use as few languages as possible.
- Kotlin for your application code base.
- Kotlin for your configuration.
- Kotlin for your html templates
- Kotlin to build the html with the templates
Hopefully you get the idea.
Note, this isn't practical with Java because Java's syntax is so rigidly C-like. Writing html using Java would be simply horrible, and that is why JSP was invented. OMG what a horror. Having used JSP and Kotlin to build html pages, I can tell you that JSP introduces so much bloat and gives nothing in return.