If you are working on a software project that have a backend or server
component, it probably have some kind of configuration. Like database
servers, maybe some API keys to upload to S3 etc. To get configurations
right, the first time is always a pain in the ass. Because some of it is
about configuring exciting tools and libraries to work with your setup,
and other times it is about configuring your stuff depending on where
you want to run it.
There are a few different ways you typically would deal with this. And
there are a few ways I would encourage you to not do.
The biggest don’t is to not put it in a database, because you might want
to take data from production and use it during development to make sure
that what you make scales well. Make sure that you don’t keep settings
that only works in production in the database. Because it will make
stuff like testing production data much harder than it has to. And don’t
just hard code settings.
The day I usually do it, is to hardcode the development settings in my
projects. And then I re-configure them to run in production. Why? The
less time I have to configure the machines of the people I work with,
the better it is. When it comes down to the actual configuration I think
there are two good ways to do it in 2018. Either with a configuration
file or with environment variables. There are places where using a
configuration file makes sense, and there are places where using
environment variables are better. A configuration file is awesome for
all kinds of settings that applies to your software project, as long as
they always are the same. The moment where it might change is when you
run into trouble. Because it is a pain in the ass to keep multiple
almost identical files up to date. A typical software project runs in
three different environment: development, staging and production.
Development is a developers personal machine, staging is where you test
stuff to make sure everything works in a production like environment and
production is where your users or customers will use it. The way I do it
these days is that everything that is not the same all places are
controlled with a environment variable. Usually through a docker-compose
What are a environment variable? Well, they are like a variable in your
programming language, except that they belong to the environment the
program runs in. This means that if you have two programs on written in
Java and one in Python that uses the same database, they can read the
same connection string.
Let’s say you have a project with two variables that change depending on
where you run it: URL and DATABASE_CONNECTION_STRING. The URL is used to
display the full URL to a resource for when you need it(for example when
sending an e-mail) and the DATABASE_CONNECTION_STRING is used to connect
to your database. I use environment variables for this because I can
just change them in the script or server configuration. Instead of
having to keep multiple copies of large config files on the project side
of it. That someone (me) have to keep in sync. On a UNIX/Linux system
you could just do something like URL=”https://yourdomain.ltd“
command-to-start-your-server to override them.
If you for some reason need to implement some project configuration on
your own. Use JSON or YAML. Most if not all developers know the formats,
and you’ll find parsers for all languages under the sun. And some in the
shadows as well.