Комментарии 10
А нельзя ли добавить в статью про JSON5? Я сейчас не скажу про отличия, но помню, что на хабре была неплохая статья про этот формат, и там довольно просто и понятно было описано, чем он лучше JSON, и тут было бы неплохо про него тоже глянуть в разрезе - чем удобно, чем нет, как и чем обрабатывается. Чтобы видно было в сравнении с другими форматами.
Различные параметры приложения могут быть:
жёстко зашиты в коде (внутри функций / методов) / hardcoded
вынесены в константы модулей
константы намного лучше, чем «магическеские числа» и «магические строки» непосредственно в коде
полезно если константы меняются крайне редко, но всё же могут меняться
вынесены в отдельные конфиг‑файлы (файлы, используемые для хранения параметров и настроек приложений).
Я бы добавил ещё два метода конфигурирования - через переменные окружения и через аргументы командной строки. Ну и никто не запрещает использовать сразу несколько методов конфигурирования, которые "наслаиваются" друг на друга.
Охх, статья скорее вредная.
Путается техническая конфигурация и бизнес-конфигурация, плюсы и минусы форматов никак не связаны с реальностью, перепутано хранение секретов и конфигурации, куча вредных советов по работе с конфигами.
Статья была бы хороша для начинающих, но в текущем виде скорее вредна для начинающих (
А каковы на твой взгляд реальные плюсы/минусы форматов?
Вообще, если для конфигов становится существенным формат хранения, значит что-то не так с дизайном и надо бы подумать. В файлах обычно есть только техническая конфигурация (а ее нужно очень мало), бизнесовая конфигурация и секреты живут в специализированных сервисах.
А так, у XML основной плюс - наличие стандартных механизмов валидации и инструментов редактирования на базе XML_Schema. Для некоторых условий это обязательное условие.
JSON - быстрый, очевидный, но сложно с комментариями и описанием.
YAML - легко читать, очень опасно редактировать, сложный стандарт с разночтениями, несовместимость между версиями. Сложно придумать, когда бы использование YAML было бы удачным.
TOML - не для всех стеков есть хорошие библиотеки с поддержкой, нетривиально заводить сложные сущности.
В реальности выбор между XML и JSON. YAML обычно является арх.ошибкой. TOML используется скорее для утилит или десктоп-приложений, не для сервисов.
Но вообще в статье почти каждый абзац вызывает много вопросов. Что, впрочем, и логично.
Благодарю за подробную и интересную статью.
Про послойные конфиги узнаю первый раз. Скажите пожалуйста, правильно я понимаю, что с учетом тех областей применения, где используются послойные конфиги, на сегодняшний день это скорее всего бОльшая часть современных приложений?
Упущена, на мой взгляд, важная (для меня так самая важная) деталь - откуда читать конфиг. Всякий раз когда приложение хардкодит конфиг внутри $HOME у меня глаз дергается.
Имхо, считаю основным следование сначала XDG спецификации, как уже де-факто стандартом, а затем гайдлайнами ОСи, на которой приложение будет работать.
Все зависит от приложений и окружения. Я в основном разрабатываю приложения баз данных в корпоративной сети для нужд компании в производстве и сервисе продукции, поэтому мне удобно хранить все настройки в БД. В основном это пользовательские настройки, но есть и системные, которые тоже можно менять из программ. В коде храню только строку подключения, за авторизацию подключения отвечает ОС. Использовать локальные файлы конфигурации неудобно и не подходит для системных настроек, которые должны быть доступны только локальному админу программы.
Всё про конфиги