Совместное использование конфигурации между Node.js, React.js и приложениями Python

Question

Мой проект в настоящее время включает в себя несколько компонентов, использующих либо Javascript, либо Python

• Node.js сервер
• Сервер API Python flask
• Скрипты обработки данных Python (numpy,pandas и т. д.)
• веб-клиент React.js
• собственный мобильный клиент React

Эти компоненты имеют несколько общих значений конфигурации, таких как строка URI подключения к базе данных postgresql://admin:password@localhost:5432/foobar используется компонентами на стороне сервера и URL-адресом сервера API https://api.example.com/v1 используется компонентами на стороне клиента.

Вопрос: Существует ли лучший способ обмена файлами конфигурации между компонентами, использующими разныеязыки?

Например,

1. Должны ли все компоненты (на стороне сервера и клиента) иметь доступ к одному и тому же файлу конфигурации? Если да, то в каком формате он должен быть, JSON, YAML и т. Д.?

2. Должны ли все компоненты иметь общий файл конфигурации (в котором хранятся только общие значения конфигурации), но также иметь второй файл конфигурации, специфичный для этого компонента?

3. Должны ли все компоненты на стороне сервера использовать один и тот же файл конфигурации, в то время как компоненты на стороне клиента имеют свои собственные отдельные файлы конфигурации?

Спасибо за советы:)

Answer 1

Я бы порекомендовал использовать TOML. Он поддерживается всеми основными языками и позволяет использовать комментарии, которых нет в JSON.

Answer 2

На мой взгляд, есть два основных подхода, которые вы увидите в дикой природе.

1. Файл конфигурации. Как нк. Как уже упоминалось, вы можете создать файл TOML, к которому могут обращаться все различные инструменты и приложения. Это хорошо, поскольку есть только один источник правды, а TOML очень удобочитаем. Минусы в том, что нужно найти TOML-парсер для вашего языка (хотя это не так уж сложно) и убедиться, что файл существует, когда скрипт / служба / все, что его ожидает. Я пошел по этому пути, и это не так уж и плохо, вы даже можете поместить файл в «облако» (NAS, общее хранилище данных, папка с широкими правами на чтение), и иметь его легко доступным, если вам нужно раскрутить больше, чемодин экземпляр службы.

2. Переменные среды. В последнее время мне понравился этот подход, так как это всегда минимальный объем конфигурации, который вы могли бы сделать, и практически любой язык имеет средства для доступа к переменным среды. Кроме того, в общедоступном текстовом файле нет конфиденциальной информации.

Для python вы бы назвали os.environ [MY_CONFIG_NAME] и presto, у вас есть информация о конфигурации.

Оба подхода являются общими и имеют широкую поддержку почти в каждомязык.

Насколько клиент, разделение сервера. Я стремлюсь сделать своих клиентов настолько «глупыми», насколько это возможно, а мои серверы - как можно более «умными».