У меня есть vue. js SPA, который я хочу развернуть на разных серверах без перекомпиляции внешнего интерфейса для каждого развертывания. SPA соединяется с бэкэндом, с URL-адресом, пока неизвестным для SPA. Есть ли способ, которым я могу динамически сообщить веб-интерфейсу во время выполнения, где находится серверная часть?
Многие статьи и ветки форума предлагают просто использовать разные конфигурационные файлы для разных сред и встраивать их во время сборки, но это не так вариант для меня, потому что я просто не знаю, где будет развернут интерфейс / бэкэнд при его создании.
РЕДАКТИРОВАТЬ: проект с открытым исходным кодом, поэтому я не могу предположить, как люди развернут это. Я всегда как бы «предполагал», что он будет развернут в отдельном поддомене, с внешним интерфейсом, доступным на /
, и с внутренним прокси с прокси на /api
, потому что так я настраивал свой сервер. Тем не менее, я видел людей, развертывающих API в совершенно другом поддомене (иногда даже с другими портами), чем во внешнем интерфейсе или на пути или даже в смеси между ними.
Вещи, которые я рассмотрел до сих пор:
- Помещение конфигурации в
conf.js
, которая затем выставляет URL-адрес бэкенда через window.config.backendUrl
или аналогичный и загружает этот файл в мой index.html
из <script>
tag - Немного похоже на 1 .: Поместите конфигурацию в
config.json
и сделайте запрос на выборку после загрузки приложения, затем выставьте результат в window.config.backendUrl
- Вставка
<script>window.config.backendUrl = 'http://api.example.com'</script>
в мой index.html
. - Обслуживание внешнего интерфейса с пользовательским веб-сервером (на основе
express
или аналогичным), который анализирует env или другой файл конфигурации, а затем создает <script>
тег из 3. динамически - Всегда «предполагая», где будет работать бэкэнд с каким-то списком, например: «Сначала посмотрите на
/api
, затем на ./api
, затем на api.current-host.com
et c. " - Объединение фронтената d с бэкэндом - таким образом, я бы всегда «знал», где находится бэкэнд по отношению к фронтэнду.
И все же все эти варианты кажутся мне немного странными, я думаю, что лучший способ.
Мой любимый - третий вариант, потому что это лучший компромисс между конфигурируемостью и производительностью ИМХО.