Я только начал изучать JavaScript/node.js (нежное введение в back-end webdev), и поэтому я полностью зеленый в теме.
Несколько дней назад я читал учебник, из которого я научился хранить свои конфиденциальные данные (например, пароли) в файле config.json.
Сегодня я обнаружил (случайно) .env файл, и чем больше я узнаю об этом, тем больше людей используют его для хранения паролей.
Поэтому, когда следует использовать .env и когда следует использовать config.json?
Когда следует .env использовать более config.json и для чего?
Это довольно сложный ответ. С одной стороны, вы должны использовать только один из этих инструментов во время разработки. Это означает, что когда в производственной или prod-подобной среде вы добавляете эти переменные непосредственно в среду:
NODE_ENV=development node ./sample.js --mongodb:host "dharma.mongohq.com" --mongodb:port 10065
Нет никакого реального явного победителя над другим как таковым, поскольку они оба полезны по-разному. У вас могут быть вложенные данные с помощью config.json, но, с другой стороны, вы также можете иметь более чистую структуру данных с .env
Также следует отметить, что вы никогда не хотите передавать эти файлы в исходный контроль (git, svc и т.д.).
С другой стороны, эти инструменты позволяют легко начинать быстро, без необходимости беспокоиться о том, как устанавливать переменные среды и различия между средой Windows и Linux.
В целом, я бы сказал, что это действительно разработчик.
.env обычно используются для хранения информации, относящейся к конкретной среде развертывания, тогда config.json файлы config.json могут использоваться для хранения данных, специфичных для приложения в целом.
либо подход работает, и независимо от того, хранятся ли ваши файлы конфигурации в вашем репозитории, больше зависит от того, должны ли данные быть конфиденциальными.
Это в значительной степени сводится к личным предпочтениям и соглашениям, которые вы используете. Это просто разные форматы для хранения такой же информации.
Некоторые примеры конфигурационных файлов:
.env*.yml (файлы YAML)*.ini (обычно только для Windows)*.jsonВ конце концов, все они выполняют одну и ту же цель: предоставить вашему приложению информацию об окружающей среде (учетные данные, пути к файлам, строки подключения и т.д.). Выберите формат, который наилучшим образом соответствует вашему выбору рамки.
Я думаю, что это действительно зависит от вас, важно помнить, почему вы используете этот подход. Идея состоит в том, чтобы сохранить ваши конфиденциальные данные в файле, который не попадает в исходный элемент управления или в другое место, отличное от вашей локальной среды - это делает данные более безопасными. Затем, когда вы будете готовы к развертыванию на удаленном сервере где-нибудь, вам необходимо вручную вставить эти значения в эту среду.
Обычно я использую .env потому что синтаксис для получения данных из .env файла поддерживается во многих удаленных средах - например, heroku. Когда я развертываю приложение в heroku, я могу войти в настройки приложения и поместить в переменные среды с помощью пользовательского интерфейса панели управления heroku - мне не нужно разбираться, как создать json файл вручную и т.д. (возможно, есть другие способы обхода). После того, как переменные на месте, я просто использую process.env.variableName для доступа к данным.
Статистическое сравнение двух пакетов NPM (вместе с другими подобными решениями) может быть лучшим решением для вас.
На момент написания этой статьи dotenv был гораздо меньшим по размеру пакетом с большей поддержкой (за исключением фактических участников, только из-за количества оставшихся проблем и огромной популярности). Он также новее на 2,5 года и, если фанфара важна для вас, имеет в два раза больше звезд.
