Почему современные приложения все чаще используют конфигурационные файлы в форматах JSON или YAML
Среди многих наших коллег очень часто возникает непонимание и даже возмущение, когда они сталкиваются с конфигурационными файлами в JSON или YAML. Основное нарекание вызывает «неудобный» формат, который заставляет контролировать пробелы или вложенность скобок.
То ли дело старый добрый текстовый конфиг. Когда-то я тоже не особо понимал это стремление и также временами возмущался свалившимися «на ровном месте» сложностями.
Но, по мере того как стал более плотно заниматься разработкой и разными обменами между разнотипными системами полностью поменял свое мнение.
Текстовый конфиг прост только на первый взгляд, с технической точки зрения это непрерывный поток символов, который нам нужно каждый раз полностью парсить и разбирать, при этом с учетом контекста, в случае, когда следующая запись относится к предыдущей.
Сложностей тут много, особенно учитывая, что строгого порядка написания конфигурационных файлов нет и тут может быть так, а там иначе.
А еще веселее становится, когда нам нужно настроить взаимодействие нескольких систем и вносит изменения в конфигурацию программно, допустим через API.
Особенно это касается всяких скриптов и панелек, которые должны сначала прочитать и показать вам текущую конфигурацию, а потом внести в нее изменения.
Каждый раз вам придется полностью читать и разбирать файл конфигурации, а потом еще решать задачу, как записать свои изменения правильно. Особенно если файл еще мог правиться вручную.
Поэтому истории известны множество историй, когда или панели ломали рабочие конфиги, либо после ручных правок ломалась работа панелей, либо сочетание этих обоих способов давало совершенно неожиданный результат.
Как быть?
Отказаться от текста в пользу структур. Основной особенностью JSON или YAML является то, что и то и другое набор объектов уровня ключ – значение, совокупность которых представляет из себя структуру.
Что такое структура хорошо известно любому, кто программирует на любом современном языке. И ее плюсы по сравнению с плоским текстом.
При этом каждый объект может как просто иметь значение, так и быть хранилищем еще одного объекта, позволяя создавать разветвленные структуры.
Но суть не в этом. Любая структура позволяет работать с собой избегая ее полного перебора.
Мы можем просто выполнить поиск по ключу и получить новую структуру, которая будет содержать только выбранные ключи и их значения.
Также просто и вносить изменения, мы находим нужный элемент структуры и добавляем в него новую пару ключ – значение.
И совершенно неважно, правили или будет править этот конфиг после нас руками. Благодаря структуре нам не надо анализировать текстовый файл и думать куда именно вставить изменения.
Есть структура и мы работаем именно с ней. В качестве примера, возьмем тот же Netplan.
Чтобы получить информацию о сетевых интерфейсах нам не надо читать весь файл, нам достаточно получить значение ключа ethernets, который будет содержать в качестве значения еще одну структуру, в которой уже ключом будет наименование сетевого адаптера.
Возможно, на первый взгляд, выглядит немного сложно, но на самом деле мы всегда знаем где что искать и откуда что удалять или добавлять, не боясь при этом пересечься с чьими-то правками и поломать синтаксис конфига.
Поэтому JSON или YAML будут все чаще использоваться для конфигурационных файлов по вполне объективными причинам.
Из минусов? Работать с ними в традиционных консольных текстовых редакторах неудобно, да это и не нужно.
В 21 веке существуют гораздо более удобные среды разработки, которые позволяют редактировать такие файлы с проверкой и подсветкой синтаксиса с рабочего ПК подключаясь к серверу по SSH.
Например, VS Code, про который мы рассказывали в нашей недавней статье:
🔹 Настраиваем Visual Studio Code для удаленной работы через SSH
