Что лучше, развернуть фронтенд и бакенд на одном домене или разных субдоменах?
Интересуют плюсы и минусы того и другого подхода.
У меня есть фронтенд часть веб-приложения (SPA, ReactJS), развернутая как докер контейнер в домене myapplication.com
И есть бакенд часть, написанная на .net core (или java), развернутая как докер контейнер на субдомене api.myapplication.com
Теперь есть два программных инженера, John и Steven. John говорит, что то, как сейчас развернуты сервисы - это правильно. Но не может обосновать почему это правильно.
А Steven говорит что лучше, чтобы фронтенд и бакенд работали на одном домене. (myapplication.com и myapplication.com/api). Но тоже не может привести убедительных аргументов почему этот подход лучше.
Лучше/хуже тут нет.
Но при использовании одного домена всё становится чуть проще:
1. Нужен всего один SSL-сертификат
2. CORS можно настроить самые строгие и всё будет хорошо работать.
Мне понравился такой ответ:
Будет ли API использоваться другими службами или он предназначен для внешнего интерфейса (например, маркетинговый сайт, мобильное приложение, третье лицо и т. д.).
Оба способа могут работать, но в этом случае отдельный поддомен разделил бы проблемы.
Если серверная часть специфична для приложения, я бы оставил ее в основном домене.
находясь на едином домене, фронт и бэк беспричинно оказываются «связаны» как минимум общей точкой входа.
Если их развязать, разместив на разных поддоменах, это позволит, например, независимо переезжать с сервера на сервер только бэку; или перенести статичный фронт на CDN, не трогая бэк.