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

Question

[Darhild]

Есть сайт, сделанный на Vue.js, для которого будет настроено три домена (для разных стран). Для каждого домена есть немного различающаяся конфигурация - разный токен для запросов по апи и разный набор языковых локалей. Не вполне понимаю, как правильно поступать в подобных случаях - создавать три копии сайта и каждый запускать со своим набором параметров, или же продуктовая сборка будет только одна, и редирект происходит на уровне nginx? В таком случае, выбор необходимой конфигурции будет происходит на фронте после проверки доменного имени (window.location.hostname), нормальная ли это практика?

Answer 1

[Aetae]

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

Comments

[Darhild]

Спасибо за ответ! Мне такая идея, наверное, больше всего нравится, но проблема в том, что сервер не на нашей стороне, и пока непонятно, до какой степени эта чужая сторона будет готова что-то сделать, кроме как выложить у себя наш фронт, ну, и редиректнуть на нужный домен.

Answer 2

[Дима Паутов]

Есть у меня 1 проект, написан на nuxt. У нас для каждого города свой поддомен по типу msk.mysite.ru и т.п.
Отличия лишь 2, это цены и страница с контактами. Для НН она одна, для остальных доменов другая. Домены реализованы через nginx. Но, т.к. у нас по итогу, на серваке фронт и бек лежат вместе, то поддомен у обоих одинаковый. А значит запрос автоматом запросит нужные данные.

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

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

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

Всё просто.

Comments

[Дима Паутов]

Немного дополнил ответ

[Darhild]

Спасибо за ответ! Всё же я сейчас больше склоняюсь к разным версиям сборки, т к выяснилось, что сайты будут также несколько отличаться по контенту - разные разделы, разные баннеры и так далее. Как-то не очень нравится идея городить в коде много разных условий в зависимости от того, какая локаль. Но ещё подумаю. А так да, у нас тоже i18n, просто перевести сайт не проблема - но там ещё дополнительная логика для каждого из доменов.

Answer 3

[Владимир Коротенко]

Это в общем то вкусовщина но почему не один домин с языковыми префиксами и фалбэком на сайт по умолчанию? Это позволит в том же роутере манипулировать не только языком но и подгрузкой компонентов в зависимости от языка. Ваш подход с разбором адреса тоже нормален

Comments

[Виталий Першин]

сео

[Владимир Коротенко]

Виталий, прекращайте бросаться аббревиатурами, объясните в чем проблема. Это уменьшит количество мусора в сети

[Виталий Першин]

Владимир Коротенко, нет проблем, все ок.

[Darhild]

Нуу, это решает уже более высокое руководство :) Там какая-то сложная политика с лицензированием этого сайта в разных странах, мб, поэтому выбрали такой вариант. Но попробую предложить вариант и с префиксами. Спасибо за ответ!

Answer 4

[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, чтобы пользователь мог зафиксировать свой выбор.

Answer 5

[grabbee]

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