Ищем альтернативу и упрощаем работу с JSON
Разработчики часто находятся между Сциллой и Харибдой: «не улучшай то, что работает» и «можно ли сделать лучше то, что и так работает отлично?». Применительно к облачной архитектуре пространство для манёвра сужается: каждое изменение может повлиять на бизнес тысяч клиентов.
Сегодня наша тема — повод задуматься и подискутировать. Мы затронем аспект облака, о котором обычно не говорят — JSON. Объекты JSON используют для разных задач. В основном это обмен данными между серверами и веб-приложениями. Формат также применяют для управления облачной инфраструктурой, интеграции с кастомными скриптами и сервисами. Есть и экзотические кейсы вроде хранения в файлах JSON записей базы данных.
Однако некоторые специалисты отмечают большое количество «синтаксического мусора», другие — ограниченную поддержку инструментов разработки. Поэтому появляются альтернативы, о которых мы и поговорим в сегодняшнем материале.
Как обеспечить масштабируемость облака
По оценкам аналитического ресурса builtwith.com, JSON используют более 180 000 сайтов. Они принадлежат не только крупным телекомам, игровым платформам и ретейлерам, но и локальным тематическим площадкам.
В то же время с JSON работают облачные провайдеры — например, задействуют его для поддержания связи между клиентскими приложениями и сервером.
Виртуальная инфраструктура может автоматизировать масштабирование сервисов через запросы API, например, с помощью Terraform. Таким образом, можно быстрее предоставлять ИТ-ресурсы с учетом пиковых периодов спроса и обеспечивать сотрудникам (или клиентам) доступ из любой точки мира.
Широкий спектр применимости ведет и к более активной критике формата со стороны специалистов. Часть неудобств связана с синтаксисом — например, всего одна лишняя запятая приводит к сбою в JSON-файле.
Нюансы JSON формата
Головную боль у разработчиков вызывают и мелкие нюансы в вопросах функциональности. Так, формат не поддерживает комментарии, его спецификация излишне строгая, а сам он плохо подходит для работы с числами в шестнадцатеричном представлении.
Для решения этих и других проблем существуют различные инструменты, в том числе открытые. Например, библиотека RapidJSON упрощает парсинг данных, а процессор jq их структуризацию.
С другой стороны, консольная утилита dasel позволяет редактировать данные в разных форматах (JSON, TOML, YAML, XML и CSV) и поддерживает их конвертацию.
Но один разработчик решил пересмотреть подход и представил альтернативу JSON — язык UCL. В теории он должен исправить некоторые проблемы «классического» формата обмена данными.
Что предлагает UCL
Его задача — сделать работу с файлами конфигураций JSON более удобной. Чтобы достигнуть этой цели, автор внес множество синтаксических изменений. Например, в UCL не нужны фигурные скобки для описания верхних объектов — можно прописать «key»: «value» вместо {«key»: «value»}.
Также необязательно использовать двойные кавычки для строк и ключей, а вместо двоеточия при их декларации ставится равно:
key = value;
section {
key = value;
}
По сути, запись выше равнозначна следующей конструкции:
{
"key": "value",
"section": {
"key": "value"
}
}
По умолчанию классический JSON поддерживает только значения в десятичной системе счисления. В UCL добавили шестнадцатеричные целые (префикс 0x), а также булевы переменные — true, yes, on и соответствующие им false, no, off. В то же время UCL поддерживает автоматическое создание массивов и комментирование — знак # для одной строки и конструкцию /*… */ для нескольких. Так, можно быстро активировать и отключать части кода.
В язык встроен макрос include для загрузки контента из других файлов в UCL-объект. В качестве атрибута макрос принимает или путь к директории, или URL:
.include "./relative/path.conf"
.include "http://example.com/file.conf"
UCL позволяет проводить валидацию объектов по схеме JSON-schema v4. Однако не поддерживает remote references. Если говорить о производительности, то автор утверждает, что UCL примерно в два раза быстрее jansson на задачах парсинга.
Что думает сообщество
В свое время проект UCL привлек внимание резидентов Hacker News. Многие встретили разработку с теплотой и положительно оценили работу с элементами так называемого «синтаксического сахара». И вокруг инструмента уже сформировалось сообщество энтузиастов — его репозиторий собрал больше 1,5 тыс. звезд.
Однако нашлись и те, кто встретил разработку с долей скептицизма, указав на ряд ограничений. Например, в формат XML инструмент переводит только собственные файлы конфигурации. Среди проблем UCL также отметили отсутствие подробной документации.
Возможно, что простой переделки кавычек и скобочек недостаточно, чтобы переманить аудиторию. Проблемы с файлами конфигураций редко связаны с синтаксическими особенностями. Чаще всего их вызывают проверки на соответствие схеме — опечатки в названии или дубли ключей. Чтобы у библиотеки было будущее, она должна решить именно эту проблему.
Если вы хотите поближе познакомиться с UCL и самостоятельно оценить его сильные и слабые стороны, то репозиторий на GitHub будет неплохой точкой для старта. В целом библиотеку можно использовать как в собственных, так и коммерческих проектах, так как она распространяется по лицензии BSD 2-Clause.
Какие есть альтернативы: HOCON и Augeas
Разумеется, UCL не единственный формат, предлагающий альтернативу и упрощающий работу с JSON. Примером может быть инструмент HOCON. Он похож на UCL, но поддерживает работу с API от Java и C#. Ориентирован на борьбу с дублированием данных и использует собственные функции «слияния» для объединения объектов или файлов, а также «подстановки» — для ссылок на другие части конфигурации или переменные среды.
Другой пример — утилита Augeas. Это — C-библиотека, которая парсит конфигурационные файлы и представляет их содержимое в виде древовидной структуры. Утилита помогает разработчикам автоматизировать взаимодействие с разными конфигурационными файлами и решает проблему несогласованности. Впрочем, инструмент официально поддерживает далеко не все виды конфигураций.
А какие альтернативы и аналоги JSON знаете вы?
Больше о возможностях масштабирования инфраструктуры:
