SPA application, авторизация и что рендерить backend'y?

Добрый день, интересуют лучшие практики по организации SPA приложения с REST API, что стоит , если вообще стоит, рендерить на стороне backend ?

Какие вижу варианты:
1. рендерим index.html, далее все view рендерим клиентом
2. рендерим сервером login page, авторизовываемся, рендерим сервером index page, далее уже клиентом
3. ничего не рендерим сервером, c REST авторизовываемся token'ом

какой подход считаете наилучшим, что применяете сами, как организовываете authentication and authorization ? Cпасибо!
  • Вопрос задан
  • 4183 просмотра
Пригласить эксперта
Ответы на вопрос 4
Fesor
@Fesor
Full-stack developer (Symfony, Angular)
что стоит , если вообще стоит, рендерить на стороне backend ?

Ничего вообще не надо редндрить. Сервер отдельно, клиент отдельно. Они никак не должны пересекаться. server-side рендеринг применяют как один из вариантов оптимизаций + для поисковиков. Это нужно далеко не всем и далеко не всегда.

c REST авторизовываемся token'ом

Еще следует помнить, что хранить секьюрные данные доступными из JS не шибко удобно (браузеры увы не предоставляют секьюрного хранилища пока-что), потому лучше токен сэтить сервером в httponly куку. Тогда браузер будет все сам разруливать и будет чуть чуть более безопасно. К сожалению другого способа в контексте SPA как организовать это дело секьюрно я не знаю. В общем случае и в localStorage хранить норм, но меня это смущает. Ну и естественно все под HTTPS, иначе все загоны по безопасности идут прахом.
Ответ написан
@kondaurov
Full stack developer
Работаем по третьему варианту. Очень удобно. Разрабатываем проекты внутри своего отдела, работаем в двоем. Я делаю restful backend. В это время коллега ставит фейковые данные и делает приложение на ангуляре. Потом когда backend готов, убираем заглушки и радуемся xD Люди, которые ставят прототип разрабатываемого проекта, не видят полной картины, и мы часто делали ошибки когда backend & frontend были сплетены и делали все по их прототипу. Сейчас можно сказать делаем по "максимуму" так как тщательно продумываю backend, нужные контролеры, модели. PS Переписали пару проектов которые были на php (фреймворк Yii): Интерфейс стал интуитивно понятным, множество контроллеров сократилось до 2 - 3х с понятными экшинами. Нету дометивации расширять проект, так как код и архитектура прозрачна
Ответ написан
Комментировать
@Milyh
Александр Кондауров Сергей Протько мне вот интересно, если вы идёте по пути 3 решения как вы делаете (если она у вас есть) авторизацию. Я имею в виду Oauth. Вот есть у вас кнопка - войти через ВК. В ссылке для этой кнопки желательно (я бы сказал - обязательно) нужно прописывать STATE - случайно сгенерированную строку для защиты от атак. Этот STATE потом проверяется на сервере. Но как его проверять, если он был сгенерирован на клиенте?
Ответ написан
matroskin13
@matroskin13
JavaScript developer, GO developer
мы в проектах юзали второй вариант. Минусы примерно такие:
1. Нету возможности полноценно разделить frontend и backend части. Часто приходится лазить в к бекенду, чтобы что-то добавлять/изменять и т.п.
2. Думал будет несколько минусов, но что-то видимо нет.

Если полностью разделить бекенд и фронтенд, это конечно классно, но нужно учитывать некоторые факторы:
1. Лишние запросы.
2. Любой желающий может чекнуть код, который реализовывает функционал для авторизированных юзеров.
но зато фронт живет отдельно от бекенда, и это очень-очень круто, особенно если у вас большой проект, имхо конечно же,
Ответ написан
Ваш ответ на вопрос

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

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