Посоветуйте, пожалуйста, как лучше использовать концепцию SPA. Мешать логику js c логикой шаблонизатора Twig, Blade и т.д. Или же фронтенд отделить целиком от бекенда, сделав бекенд чисто REST ?
Перерыл кучу материала, но в примерах в основном код angular мешают с кодом шаблонизатора, как мне кажется получается треш на вид. Но почему-то такой подход используют чаще всего.
Проблемы индексации пока не берем в расчет, интересует прежде всего подход при разработке больших проектов и какие могут быть подводные камни.
Мешать логику js c логикой шаблонизатора Twig, Blade и т.д. Или же фронтенд отделить целиком от бекенда, сделав бекенд чисто REST ?
Да, клиент отдельно, сервер отдельно, между ними HTTP API.
Если у вас будут проблемы связанные со скоростью бутстраппинга и т.д. то вместо того что бы "смешивать" шаблонизатор и angularjs (это вообще тупо), можно просто при запросе на сервак подготовить данные и вшить их в страницу (пробрасывая все через JS).
capscom: не особо. Смотря как делать, у меня все эти данные (что чувак может) зашиты в JWT токен. Прятать кнопки что бы не давать чуваку что-то делать - наука не хитрая. Пишем директивку для этого или вообще на уровне загрузчика темплейтов все делаем.
Уж не знаю, где вы нашли кучу SPA примеров со смесью шаблонизаторов и Angular JS, но делать так явно не рекомендуется.
Делайте REST бекенд и отдельное приложение на фронтенде на Angular JS.
capscom: Это же полный бред. Мне вообще довольно трудно представить, как SPA будет работать с бекендовым роутингом. Когда у вас на странице может, например, быть 3-4 разных вьюшки, внутри которых совершенно несвязанные между собой компоненты.
Если так, то поддерживаю Николай , разделяйте проект на js клиент и сервер c HTTP REST API. Практиковал такой подход с django и angular, полёт нормальный. Как мне видится подход с разделением зон ответственности удобен, когда руку набьёшь пишется быстро.
Простой
Средний
Простой
Простой
