Существует два основных подхода к описанию конфигурации: использовать код на каком-то языке (возможно dsх) или описывать все через универсальные форматы (yaml, json).
Например большинство линтеров и форматеров используют конфигурацию через json файлы. Хотя в JS экосистеме происходит сдвиг в сторону написания конфигурации для таких инструментов в js файлы. Системы сборки чаще делают кодом, например gradle или классический Make, хотя тот же maven использует xml.
Оба подхода широко распространены даже в рамках одной задачи, но разных стеках. Выбор не всегда очевиден и любой разработчик, которому приходится его делать, находится какое-то время в замешательстве.
Конфигурация на данных кажется классной идеей и практически незаменима, когда нам надо шарить ее между разными экосистемами. Классный пример это openapi спека. Она нужна и на беке и во фронте и внешним клиентам, которые пишутся на бог знает чем. При том что писать ручками саму спеку еще тот геморрой, поэтому вокруг созданы целые языки (не тьюринг полные) типа typespec, которые умеют генерить openapi спеку.
@route("/stores")
interface Stores {
list(@query filter: string): Store[];
read(@path id: Store): Store;
}
Но у такого подхода есть и масса ограничений. Во-первых сразу забываем про синхронизацию с кодом. Если конфигурация содержит имена модулей, классов, в целом какие-то связи с кодом, то в lsp придется встраивать доп поддержку, что вообще врядли кто-то будет делать. Во-вторых, есть места, где нужно иметь какое-то кастомное поведение, типовая задача замутить что-то этакое во время сборки. Если у вас конфигурация описана данными, то вы физически не сможете реализовать кастомное поведение без расширение языка конфигурации. Такое тоже, кстати, встречается. Возьмите ansible, можно написать свои модули.
Если описывать все это кодом, то мы получаем возможность достаточно легко писать кастомную логику, у нас включается lsp, начинает работать автокомплит проверка типов и многое другое. Но пожалуй главная проблема, в том что такой уровень свободы приводит к ситуациям, когда конфигурация превращается в полноценный код, который хрен поймешь и который желательно еще и тестировать из-за его сложности. А уж отладку каких-нибудь хитрых штук многие вспоминают как в страшном сне.
Иногда это приводит к решению пойти третим путем. Создать под конфигурацию свой собственный язык, который и конфигурацию на выходе может дать и при этом позволяет делать больше и удобнее чем тот же json. Например terraform. Но это не самый легкий путь, потому что для него нужно писать целую экосистему инструментов, но для фундаментальных вещей, как мы видим, это работает. При этом даже терраформ довольно ограничен и есть альтернативные решения, где все по настоящему программируется.
Так и что выбирать и на что ориентироваться? Как будто универсального ответа нет, видно как инструменты постоянно прыгают туда сюда и часто есть альтернатива для тех кто хочет гибкость (язык) или наоборот строгость (данные) со всеми плюсами и минусами описанными выше
p.s. Лиспофилы щас бы сказали что у нас два в одном и конфигурация и код описываются данными. Но это немного лукавство, потому что код как данные в лиспах имеет значение только внутри самих лиспов при написании макросов. Для внешних систем это не данные, которые можно взять и использовать
Ссылки: Телеграм | Youtube | VK