Как управлять настройками среды в приложениях JavaScript

kak upravlyat nastrojkami sredy v prilozheniyah javascript

Сегодня многие веб-приложения созданы с помощью React, Angular, Vue, Ember и других. Эти современные приложения, отображаемые на стороне клиента, часто вызывают веб-интерфейсы API, размещенные на отдельных серверах. Это создает проблему: как настроить приложение для вызова правильного URL-адреса API в каждой среде?

Например, при разработке вы можете разместить API локально на localhost:3000. В производстве API может быть размещено на другом сервере на api.mycompany.com. Итак, вам нужно, чтобы ваше приложение вызвал localhost:3000 в разработке и api.mycompany.com в производстве. Но как?

И базовый URL-адрес является лишь одним из примеров настроек, которые могут изменяться в зависимости от среды. Для повышения производительности, безопасности или журналирования можно настроить другие параметры для каждой среды. Некоторые из следующих подходов можно применить к общим конфигурациям среды. Но для простоты, эта публикация посвящена методам настройки базовых URL для каждой среды.

Я опубликовал в Twitter опрос с несколькими вариантами:

Оказывается, есть много способов справиться с этим. Я получил много проницательных ответов в цепочке твитов. Ниже я подытожил восемь вариантов. Я упорядочил эти варианты (приблизительно) в том порядке, в каком их следует рассматривать. Итак, если вы спешите, варианты, которые следует рассмотреть, находятся наверху. ?

Вариант 1. Разместите API вместе с приложением

Просто. Просто разместите приложение и API на одном веб-сервере, чтобы относительные URL-адреса работали повсюду. Это позволяет избежать проблемы как с базовым URL-адресом, так и с перекрестным источником.

Когда это рассматривать:

  • Ваш API используется одним приложением.
  • Вам не нужно масштабировать API и приложение отдельно, поэтому размещение на одном сервере практично.

Вариант 2: Специальный сборник среды

Этот подход придерживается принципа при компиляции:

Никогда не делайте во время выполнения того, что вы можете справиться во время компиляции.

При таком подходе обычно используется сервер непрерывной интеграции (CI) для создания и развертывания специальных сборок для каждой среды. Это мощный, безопасный и универсальный подход, но требует от каждого разработчика создания и поддержки файла .env на своем компьютере. Вот замечательная публикация с некоторыми уловками, как сделать это достаточно безболезненным.

Когда это рассматривать:

  • Вам удобно настраивать сервер CI для автоматизации процесса создания и развертывания для обеспечения надежности.
  • Вы хотите существенно изменить код, развернутый в производстве, например, удалить код, который используется только в непроизводственных средах из соображений производительности или безопасности.
  • Вы спокойно относитесь к риску, связанному с развертыванием в производство кода, отличного от того, который вы запускали при разработке и контроле качества.

Вариант 3: Конфигурация среды выполнения

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

Есть несколько возможных способов передать данные конфигурации среды:

  1. Конфигурация командной строки — Передайте конфигурацию при запуске программы.
  2. Файл конфигурации среды — Заполните файл .env в каждой среде и читайте его во время запуска. Вот пример из документов create-react-app, но этот подход применим к любой программе JavaScript.

Но как ваша программа получает эту информацию? Также есть несколько способов сделать это:

  1. Файл конфигурации — Запись конфигурационных данных в отдельный файл JavaScript при запуске программы. Приложение может импортировать и читать этот файл при запуске.
  2. Глобальный в index.html — Запишите конфигурационные данные в глобальный файл в index.html с помощью инструмента сборки. Опять же, вот пример из документов create-react-app, но этот подход применим к любой программе JavaScript.

Следует признать, что эти подходы несколько изменяют ваш код при запуске на основе предоставленной конфигурации среды выполнения. Но они отличаются от варианта №2 выше, поскольку тот же код разворачивается во всех средах.

Когда это рассматривать:

  • Вы предпочитаете развертывание того же кода во всех средах.

Вариант 4: Обратный прокси

С помощью этого подхода вы вызываете тот же относительный URL во всех средах. Как это работает? Ответственность переднего веб-сервера состоит в том, чтобы переадресовывать вызовы в соответствующий API для каждой среды. Этот подход имеет несколько преимуществ:

  1. Ваши URL-адресы во всех ваших вызовах API являются чистыми, относительными URL-адресами. К примеру /user.
  2. Вы можете настроить внешний веб-сервер как уровень кэширования для повышения производительности.
  3. Этот подход поддерживает переключение внутренних систем путем простой перенастройки прокси-сервера.

Когда это рассматривать:

  • У вас есть возможность настроить веб-сервер в любой среде
  • Вы заинтересованы в реализации уровня кэширования между вашим пользовательским интерфейсом и вашим API.
  • Ваш внешний веб-сервер может надежно и быстро переадресовывать вызовы на сервер API. Этот подход имеет затраты на производительность, поскольку ваш веб-сервер должен передавать запросы на другой сервер.

Дополнительное примечание:

Пока мы говорим о прокси, еще один подход к прокси, о котором стоит упомянуть, – промежуточное программное обеспечение (это совсем другой подход, чем обратный прокси, рассмотренный выше).

Если промежуточное программное обеспечение прокси-сервера работает на вашей локальной машине, запросы пересылаются на указанный URL-адрес при разработке. К примеру, если вы разработчик React, create-react-app имеет встроенную поддержку прокси. Он использует промежуточное программное обеспечение прокси Webpack.

Вот полный обзор прокси-подхода с использованием React и Express.

Однако: промежуточное программное обеспечение прокси решает только проблему базового URL при разработке. Поэтому используйте одну из других техник в этой публикации для управления другими средами, такими как контроль качества и производство.

Вариант 5: Докер

С помощью Docker вы можете развернуть пользовательский интерфейс и API как отдельные контейнеры, но создать «локальную сеть», которая позволит контейнерам общаться так, будто они находятся в одной сети. Таким образом, базовые URL-адреса не изменяются в каждой среде. Контейнеры работают одинаково во всех средах. И вы можете передать соответствующие переменные среды в контейнеры в каждой среде. Просмотрите этот подход в Kubernetes или Docker Swarm.

Когда это рассматривать:

  • Вы уже инвестировали в экосистему Docker.

Вариант 6: Вынюхивание среды

При таком подходе вы используете код, чтобы «нюхать»?? текущая среда, как правило, смотря на URL-адрес. Например, если вы знаете, что URL-адрес находится в разработке.

Преимуществом этого подхода есть простота. Разработчикам не нужно ничего настраивать на своем компьютере, и вам также не нужно баловаться конфигурациями сервера CI или веб-сервера.

Когда это рассматривать:

  • У вас есть простое приложение, которое вызывает небольшое количество API.
  • У вас нет CI-сервера.
  • Политика вашей компании делает болезненным или непрактичным внедрение других вариантов, приведенных выше.
  • Вас не волнует, что люди потенциально найдут URL-адреса вашей непроизводственной среды. (Из соображений безопасности ваша непроизводственная среда все равно не должна быть доступна за пределами вашей корпоративной локальной сети/VPN).

Настройте внешний веб-сервер для предоставления специального заголовка HTTP, содержащего соответствующий URL клиента для среды. Недостатком этого подхода является то, что ваше приложение должно сначала сделать HTTP-вызов к этому API, чтобы определить, какие соответствующие базовые URL-адреса для всех сред.

Когда это рассматривать:

  • Я не рекомендую этот подход, поскольку он требует, чтобы ваша программа совершила двусторонний HTTP-вызов, прежде чем она сможет фактически начать получать данные. Я предпочитаю один из приведенных выше подходов.

Вариант 8: конечная точка конфигурации программы

При таком подходе ваша программа вызывает тот же API конфигурации программы по тому же URL для всех сред. Ваше приложение сначала вызывает этот API. Вызов API возвращает соответствующий базовый URL-адрес в каждой среде (а также потенциально включает другие настройки среды). С помощью такого подхода вы можете передать вместе с другими соответствующими конфигурационными данными среды.

Когда это рассматривать:

  • Я тоже не рекомендую этот подход. Это влияет на время загрузки, поскольку исходный вызов HTTP для получения конфигурационных данных должен завершиться, прежде чем приложение сможет фактически начать получать нужные данные. Рассмотрите один из приведенных выше вариантов.

Резюме

Создайте сборку для каждой среды через сервер CI, если вам нужна подлинная настройка для каждой среды (№2 выше). Если вы предпочитаете развертывать тот же код в каждой среде, рассмотрите конфигурацию среды выполнения (№3 выше) или обратный прокси (№4 выше).

Счастливого кодирования! ⌨️

У вас есть другие способы справиться с этим? Пожалуйста, подключитесь через комментарии.

Кори Хаус является автором нескольких курсов по JavaScript, React, чистого кода, .NET и т.д. на Pluralsight. Он является главным консультантом reactjsconsulting.com, архитектором программного обеспечения, MVP Microsoft и обучает разработчиков программного обеспечения по всему миру практикам внешней разработки. Кори твитирует о JavaScript и интерфейсной разработке в Twitter как @housecor.

Добавить комментарий

Ваш адрес email не будет опубликован.