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

Есть сайт, сделанный на Vue.js, для которого будет настроено три домена (для разных стран). Для каждого домена есть немного различающаяся конфигурация - разный токен для запросов по апи и разный набор языковых локалей. Не вполне понимаю, как правильно поступать в подобных случаях - создавать три копии сайта и каждый запускать со своим набором параметров, или же продуктовая сборка будет только одна, и редирект происходит на уровне nginx? В таком случае, выбор необходимой конфигурции будет происходит на фронте после проверки доменного имени (window.location.hostname), нормальная ли это практика?
  • Вопрос задан
  • 466 просмотров
Решения вопроса 3
Aetae
@Aetae
Тлен
Просто делай отдельный файл конфига\локали и пусть сервер подгружает в соответствии с доменом. Самому билду вообще лучше ничего не знать о конкретных доменах, для лёгкой переносимости.
Ответ написан
bootd
@bootd
Гугли и ты откроешь врата знаний!
Есть у меня 1 проект, написан на nuxt. У нас для каждого города свой поддомен по типу msk.mysite.ru и т.п.
Отличия лишь 2, это цены и страница с контактами. Для НН она одна, для остальных доменов другая. Домены реализованы через nginx. Но, т.к. у нас по итогу, на серваке фронт и бек лежат вместе, то поддомен у обоих одинаковый. А значит запрос автоматом запросит нужные данные.

Если у вас именно разные сборки для разных доменов. То делаете множество билдов для разных доменов. А nginx будет брать нужную и отображать.

Делать разные сайты очень глупо. В случае, если домен у api один, а фронт живёт сам по себе на другом, достаточно просто посылать заголовок с городом бекенду, который сам должен рулить нужными данными.

Есть в практике другие сайты, мультиязычные. Использовали i18n для превода интерфейса. Перевод хранится в json файлах, для нужной локали загружается нужный json. Так же, бекенду передаётся в заголовке с запросом текущая локаль, для того, что бы бекенд отдавал контент с нужным переводом.

Всё просто.
Ответ написан
firedragon
@firedragon
Senior .NET developer
Это в общем то вкусовщина но почему не один домин с языковыми префиксами и фалбэком на сайт по умолчанию? Это позволит в том же роутере манипулировать не только языком но и подгрузкой компонентов в зависимости от языка. Ваш подход с разбором адреса тоже нормален
Ответ написан
Пригласить эксперта
Ответы на вопрос 2
@Stan_1
Выбор по языку можно делать не только на фронте, но и настройками ngnix. Примерно, как описано вот здесь.

https://github.com/giom/nginx_accept_language_module

У меня трехязычный сайт, и там действует такая логика (на уровне NGNIX):
1. Установлена ли кука user_lang?
2. Если да, то она равна "en"? Если да - открываем https://example.com
3. Если кука есть, но не равна "en", открываем https://example.com/$user_lang
4. Если куки нет, и браузер имеет язык "ru" или "es", открыть https://example.com/ru или https://example.com/es
5. Если куки нет, и браузер имеет язык не "ru", и не "es", открыть https://example.com

Соответственно, в самом приложении, при выборе языка из списка, ставится кука user_lang, чтобы пользователь мог зафиксировать свой выбор.
Ответ написан
grabbee
@grabbee
Если контент различается, то три разных сайта. Если контент (база данных[данные]) идентичные - то бэк/апи тоже можно один оставить и разруливать на уровне переменных окружения сервера и настроек на клиенте. Не вижу ничего плохого в трех идентичных сайтах даже при одном наполнении. Легче будет масштабировать и мониторить. Три сервера будут отличаться только переменными окружения, а база данных может быть общая.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы