We are looking for an alternative and simplify the work with JSON
Developers often find themselves between Scylla and Charybdis: “don’t improve what works” and “is it possible to make something better that already works perfectly?”. With regard to cloud architecture, the room for maneuver is narrowing: each change can affect the business of thousands of customers.
Today our topic is an occasion to think and discuss. We will touch on an aspect of the cloud that is usually not talked about – JSON. JSON objects are used for different purposes. Basically, this is the exchange of data between servers and web applications. The format is also used for cloud infrastructure management, integration with custom scripts and services. There are also exotic cases like storing database records in JSON files.
However, some experts note a large amount of “syntax garbage”, others – limited support for development tools. Therefore, there are alternatives, which we will talk about in today’s material.
How to ensure cloud scalability
According to the analytical resource builtwith.com, more than 180,000 websites use JSON. They belong not only to large telecoms, gaming platforms and retailers, but also to local thematic sites.
At the same time, cloud providers work with JSON – for example, they use it to maintain communication between client applications and the server.
A virtual infrastructure can automate service scaling through API requests, such as with Terraform. In this way, IT resources can be provisioned faster to meet peak demand periods and provide employees (or customers) with access from anywhere in the world.
A wide range of applicability leads to more active criticism of the format by experts. Part of the inconvenience is related to the syntax – for example, just one extra comma leads to a crash in the JSON file.
Nuances of JSON format
Minor nuances in terms of functionality also cause headaches for developers. For example, the format does not support comments, its specification is overly strict, and it itself is not well suited for working with numbers in hexadecimal representation.
To solve these and other problems, there are various tools, including open ones. For example, the RapidJSON library simplifies data parsing, while the jq processor simplifies their structuring.
On the other hand, the console utility dasel allows you to edit data in different formats (JSON, TOML, YAML, XML and CSV) and supports their conversion.
But one developer decided to rethink the approach and introduced an alternative to JSON – the UCL language. In theory, it should fix some problems of the “classic” data exchange format.
What UCL offers
Its purpose is to make working with JSON configuration files more convenient. To achieve this goal, the author has made many syntactic changes. For example, UCL does not need curly braces to describe top objects – you can write “key”: “value” instead of {“key”: “value”}.
It is also not necessary to use double quotes for strings and keys, and instead of a colon, they are declared equal to:
key = value;
section {
key = value;
}
In fact, the entry above is equivalent to the following construction:
{
"key": "value",
"section": {
"key": "value"
}
}
By default, classic JSON only supports decimal values. Hexadecimal integers (prefix 0x) were added to UCL, as well as boolean variables – true, yes, on and their corresponding false, no, off. At the same time, UCL supports automatic array creation and commenting – the # sign for one line and the /* … */ construct for several. So, you can quickly activate and deactivate parts of the code.
The language has an include macro for loading content from other files into a UCL object. The macro accepts either a path to a directory or a URL as an attribute:
.include "./relative/path.conf"
.include "http://example.com/file.conf"
UCL allows you to validate objects according to the JSON-schema v4 schema. However, it does not support remote references. In terms of performance, the author claims that UCL is about twice as fast as jansson on parsing tasks.
What the community thinks
At one time, the UCL project attracted the attention of Hacker News residents. Many greeted the development with warmth and positively evaluated the work with elements of the so-called “syntactic sugar”. And a community of enthusiasts has already formed around the tool – its repository has collected more than 1.5 thousand stars.
However, there were also those who met the development with a share of skepticism, pointing out a number of limitations. For example, the tool translates only its own configuration files into XML format. Among the problems of UCL also noted the lack of detailed documentation.
It is possible that simply rewriting quotes and brackets is not enough to lure the audience. Problems with configuration files are rarely related to syntactical features. Most often they are caused by checks for compliance with the scheme – typos in the name or duplicate keys. For the library to have a future, it must solve exactly this problem.
If you want to get to know UCL better and evaluate its strengths and weaknesses for yourself, then the GitHub repository is a good place to start. In general, the library can be used both in your own and commercial projects, as it is distributed under the BSD 2-Clause license.
What are the alternatives: HOCON and Augeas
Of course, UCL is not the only format that offers an alternative and makes JSON easier to work with. An example would be the HOCON tool. It is similar to UCL but supports Java and C# APIs. Focused on combating duplication of data and uses its own “merge” functions to merge objects or files, as well as “substitution” – to refer to other parts of the configuration or environment variables.
Another example is the utility Augeas. This is a C library that parses configuration files and presents their contents in a tree structure. The utility helps developers to automate the interaction with different configuration files and solves the problem of inconsistency. However, the tool does not officially support all types of configurations.
And what are the alternatives and analogues JSON do you know?
Learn more about infrastructure scalability:
