Comments 5
Интересно будет поглядеть, что получится. А пока вопрос: зачем проксировать запросы на бэкэнд?
Спасибо, хороший вопрос!
В целом, практика показывает что данный подход является наиболее гибким и, в конечном счете, удобным для подобных проектов. Позволяет избежать всевозможных костылей во время реализации (п.7 манифеста).
Более того, в данном случае, этот подход является неизбежным, потому что мы хотим обеспечить работу без JS на клиенте.
Кроме всего прочего, проксирование открывает некоторые дополнительные возможности:
На самом деле полезных кейсов еще больше.
В целом, практика показывает что данный подход является наиболее гибким и, в конечном счете, удобным для подобных проектов. Позволяет избежать всевозможных костылей во время реализации (п.7 манифеста).
Более того, в данном случае, этот подход является неизбежным, потому что мы хотим обеспечить работу без JS на клиенте.
Кроме всего прочего, проксирование открывает некоторые дополнительные возможности:
- Перехват клиентских атак, типа XSS/CSRF/etc.;
- Сокрытие бекенд сервера + нет необходимости включать CORS на бекенде;
- Возможности изоморфного кэширования данных и запросов;
- Более безопасная работа с сессиями/токенами/итп;
- Перехват запросов/ответов и внесение точечных изменений. Часто пригождается,
когда необходимо интегрироваться с «legacy» или неподконтрольным бекендом; - Изменение способа авторизации. Например довольно удобно навешивать OAuth поверх существующего бекенда;
- Упрощенная реализация асинхронного «stateful» функционала поверх синхронных «stateless» бекендов. Реальный кейс: websocket'ы для бекенда на PHP.
На самом деле полезных кейсов еще больше.
Sign up to leave a comment.
Разработка изоморфного RealWorld приложения с SSR и Progressive Enhancement. Часть 1 — Введение и выбор стека