JSON format, intended initially to replace XML for data-interchange, is widely used today to provide public data using APIs and web services as well as to write various configuration files.

JSON can store information in an organised, human-readable and machine-readable format, but the emerging trend of writing configurations in JSON is something that a lot of people don’t like.

Before I reveal the awesome way to tackle the problem, Let’s quickly see why people believe it is a bad idea to write configuration in plan JSON format.

No comments allowed

Weird, right! You’re not allowed to add any comments in the JSON file, which sometimes encourages people to write ugly code like below.

Not so good way to put comments in JSON files.

Excessive duplicates

In most of the configurations, I’ve experienced there are sections/values which are used multiple times in the same or multiple JSON configuration files. I’m sure you would have With the plain JSON format, there is no way to avoid duplication.

Consider below example of an environment configuration file, where the IP address “10.0.0.120” is used three times in a single configuration file.

Imagine this same IP address is used multiple times in other configuration files. How would one track if we need to change this IP in future or how would one remove the duplicate entries without changing the schema?

You might think why can’t just put a placeholder and use a programming language to replace placeholders with the actual values. Well, a lot of people do that but I’ll explain later in this article why putting placeholders is not a good idea.

Zero programmability

With the plain JSON, you can’t do cool geeky stuff like variables, conditional statements, loops, or import other JSON files etc.

To output, the data from a REST API or web service, programmability in JSON might not look useful. But when writing configurations, programmability will add a lot of value and save a lot of extra efforts to make the code clean and re-usable.

Consider below example of a monitoring configuration file to monitor four services in production, dev and test environments.

Do you imagine it is easy to write and read the above configuration?Well! Maybe not too difficult. However, think of following different scenarios, where writing configuration in JSON might be complicated:

• We have fifty or even more different services to monitor in five or more environments.
• Some of the services exist in production but not in non-production environments.
• FQDN (fully-qualified-domain-names) for the services are dynamic and imported from other files.