Развертывание одной и той же сборки веб-приложения Javascript в разных средах

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

Для последних двух сред я хочу собрать ОДНУ сборку приложения ExtJS и сначала развернуть ее на тестовом сервере, а затем, когда она будет готова к выпуску, развернуть точно такую ​​же сборку на рабочем сервере.

Вопрос: Можно ли как-то использовать среду, где развернут фронтенд, чтобы решить, к какому бэкенду подключаться ExtJS? Поскольку внешний интерфейс ExtJS выполняется на клиентской машине, он не знает, должен ли он подключаться к рабочему или тестовому серверу.

Каков наилучший способ решения такой проблемы? Как (в чистом виде) обычно веб-приложение javascript создается и развертывается в нескольких разных средах и взаимодействует с соответствующим бэкэнд-приложением?


javascript client-side extjs extjs6
person Niklas    schedule 19.08.2015    source источник
comment
Отказ от ответственности: я ничего не знаю о extjs, но я думаю, что вы могли бы добавить API для обработки этого. Например: оба сервера (в сети) отвечают на определенный пакет/http-маршрут/что угодно с текущей версией, в которой они находятся. Если оба сервера работают и оба имеют одинаковую версию, интерфейсный сервер может указать интерфейсу подключиться к последнему серверу. Фронтентный сервер будет проверять эти API каждый раз при запуске или каждые n минут/секунд/независимо от того.   -  person Florian Wendelborn    schedule 19.08.2015

Ответы (1)


arrow_upward
0
arrow_downward

Как (в чистом виде) обычно веб-приложение javascript создается и развертывается в нескольких разных средах и взаимодействует с соответствующим бэкэнд-приложением?

Ну случай не очень обычный. Обычно внутреннее приложение будет (по крайней мере, на первый взгляд) на том же сервере, с которого загружается внешнее приложение. Таким образом, вероятно, самый беспроблемный способ выполнить вашу задачу — сделать запросы прокси внешнего сервера от внешнего приложения к соответствующему внутреннему серверу. Таким образом, внешнее приложение по-прежнему будет взаимодействовать со своим исходным сервером, что позволяет вам иметь только одну сборку для всех сред.

"Официальным" способом было бы использовать разделы для каждой среды в файле app.json следующим образом:

"production": {
    "backend": "backend.domain.tld",
    // other stuff
},
"testing": {
    "backend": "backend.testing.domain.tld",
    // other stuff
},
"development": {
    "backend": "backend.dev.domain.tld",
    // other stuff
}

Значение backend окажется в файле сборки classic.json (и/или modern.json). Приложение внешнего интерфейса увидит значение как Ext.manifest.backend. Но этот способ эффективно создает разные сборки, которых вы хотели избежать. Таким образом, вы можете просто вручную создать несколько версий файлов classic.json/modern.json для ОДНОЙ производственной сборки следующим образом:

  • classic.json.testing
  • classic.json.staging
  • classic.json.production

а затем используйте перезапись на внешнем сервере, чтобы отвечать на запросы «/classic.json» любым файлом json, соответствующим назначению сервера.

Тем не менее, еще один способ состоит в том, чтобы сохранить сопоставление между интерфейсом и сервером для ВСЕХ сред во внешнем приложении следующим образом:

var ENV_CONF = {
    'frontend.testing.domain.tld': 'backend.testing.domain.tld',
    'frontend.staging.domain.tld': 'backend.staging.domain.tld',
    'domain.tld': 'backend.domain.tld' // production
};

Приложение будет использовать location.host в качестве ключа и обращаться к соответствующему бэкенду.

person Greendrake    schedule 19.08.2015