Как правильно разделять бэкенд и фронтэнд в сложных веб-приложениях?

Question

[undeadter]

Как правильно разделять бэкенд и фронтэнд в сложных веб-приложениях?

Например разрабатывается сложное приложение с использованием django, symfony или других фреймворков. Для фронтенда например используется angularJS. Взаимодействие должно быть полностью разделенным должно быть? Например с помощью REST API? Или в вьющках подключать Angular для каждого приложения? Интересует то, как можно больше сделать независимые приложения, и то, как фронтенд разработчики разрабатывают представления независимо от бэкенд разработчиков в продакшене при разработке сложных проектах.

Comments

[sim3x]

слишком общий вопрос

Answer 1

[Сергей Протько]

SPA - полноценное самодостаточное приложение, а потому вынести это добро в отдельный репозиторий - вполне себе нормальное решение. Аналогия - разработка мобильных приложений и бэкэнда к оному. Вести такую разработку в одном репозитории как минимум будет неудобно.

И если с мобильными приложениями все понятно, то с фронтэндом могут быть замуты. Например, вы хотите сделать страничку логина просто на Symfony/Django, и потом редиректить уже на SPA после того, как будет получен аутентификационный токен.

опять же я не вижу никаких проблем в этом случае держать все в разных репозиториях и использовать фронтэнд как зависимость к бэкэнду (что бы уже собранное фронтэнд приложение подключалось).

или еще интереснее. Какой-то прелоад данных. Например мы можем захотеть заинлайнить в html какие-то данные, которые генерит бэкэнд. Чтобы эти данные были доступны клиенту еще до того, как загрузится ангуляр. В этом случае опять же мы можем генерить точку входа при помощи готового html шаблона, поставляемому нам со стороны фронтэнда и силами какого-нибудь twig/jninja инлайнить json в тело страницы:

function data() {
    return {{data | json}};
}

Но это оооочень редкие кейсы.

Comments

[zelsky]

А разве СПА не сингл пейдж апликейшн ?

[Денис Букреев]

BlastPy: неа, это полноценное самодостаточное приложение)

[Сергей Протько]

BlastPy: именно оно, single page application. самодостаточное приложение.

Answer 2

[Zada]

Важно понимать, какого рода проект рассматривается. Если это будет действительно приложение которое годится для SPA, то совет с полностью независимой разработкой, в отдельных репо - годный.

Если же проект контентный и будет часть доступная поисковикам, анонимвм и все такое - все сложнее и скорее, при сильном желании использовать angular придется делать много SPA. И выборочно.

Все дело в том, что с развитием проекта, когда встанут вопросы о поисковиках, скорости и всяком таком, окажется, что angular совершенно к этому не годен. Вещи вроде prerender решают проблему исключительно в простейших случаях и при развитии функционала требуют не тривиальный подходов и другой лабуды. Здесь речь идет о редиректах, 404, возможности ставить мета теги, noindex и все такое.
Люди могут заявлять, что и 404 и 301/302 prerender поддерживает, но усилия в которые все это выливается в 100 раз превосходят те, что требуются при стандартном подходе, когда html отдает бекенд.

Т.е. angular и ему подобные приносят пользу только в случае правильного применения.

В вопросе не прозвучало о специфике проекта, потому, возможно мои слова не к месту, однако - предупрежден - вооружен.

Спасибо.

Answer 3

[xmoonlight]

Просто делаете RESTful API на бэке, а в качестве клиента - используете всё что угодно: SPA, натив, мобильное и т.д.
Т.е., никогда не связывайте: логику, обмен данными и их представление.
По аналогии с машинами: клиент - рычаги, сервер - механизм, передача данных - тяги.
Проектируйте - точно также, исходя из того, какие данные и как должны выглядеть на клиенте и какие "рычаги" предоставить пользователям.

Answer 4

[Alexey]

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