@lucienwebdev

Зачем держать клиент и сервер на одном домене?

Предположим, есть у меня какая-то статика html, css, js и есть отдельный сервер, в чем необходимость держать их на одном домене, скажем mydomain.com для клиента и api.mydomain.com для апи, зачем так делают? В чем проблема, скажем, держать их в отдельности друг от друга?
  • Вопрос задан
  • 167 просмотров
Пригласить эксперта
Ответы на вопрос 2
Kozack
@Kozack
Thinking about a11y
Один домен избавляет вас возни с CORS
Ответ написан
@mletov
1) Например, на одном домене стоят клиентский и серверный фреймворк, пусть будет Angular и Laravel, но это в принципе неважно. У каждого свой рутинг и надо следить чтобы правила в этих рутингах друг с другом не конфликтовали. У меня вот всегда была проблема понять, чей рутинг главнее и какое правило отработает первым.
Не то чтобы это прям непосильная задача, мануалов о совместном использовании фронта и бэка на одном домене хватает, но все равно мне так спится спокойнее, когда каждое приложение живет своей жизнью. Пока приложение простое и правил мало - не критично.

2) Если на проекте не фулстеки, а отдельные узкие спецы, то незачем фронту ковыряться в бэке, а бэку - во фронте. У каждого свои доступы, свой код, свой уровень ответственности.

3) В некоторых случаях к API обращается не только бэк, но и, например, мобильное приложение.
Тут идеологически правильно рассматривать API как нечто отдельное и самобытное, не валить все в кашу.

4) Меньше связанность. Вот был у вас бэк на PHP, а решили вы его переписать на Node.js, .NET или Java.
Когда бэк сделан отдельным проектом, то возни будет меньше.

Хотя на маленьких проектах или в команде фулстеков можно и не разделять.
Единого правила тут нет, все сугубо по ситуации. Обратная сторона медали в виде возни с CORS, про которую упомянули выше, тоже имеется.
Ответ написан
Комментировать
Ваш ответ на вопрос

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

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