Развертывание одного и того же Javascript webapp сборки в разных средах

Question

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

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

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

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

Answer 1

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

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

«официальный» способом было бы использовать секции за охрану окружающей среды в 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) файл. Приложение Frontend увидит значение 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 в качестве ключа и поговорить с соответствующим бэкэндом.