Стоит ли применять SSR в React для сайтов формата блог?
Добрый день.
По рекомендациям местных гуру я решил рассмотреть React для создания фронта с применением серверного рендеринга.
Продукт для меня новый и появляются после прочтения статей следующие вопросы:
1. полагаю, что нагрузка на сервер вырастает заметно в сравнении с отдачей традиционной html без react и это повлечет временные затраты, прежде чем отрисуется первый байт.
2. большой вес даже маленькой страницы. Логика извлечения данных из компонентов становится неоправданно затратной с точки зрения ресурсов и времени кодинга). Выгружать придется все те же скрипты, css, медиа — которые отсутствуют в html и объект для redux — который уже присутствует в html, а также DOM элементы, сформированные React. Размер разворачиваемых данных вырастает, возможно, на несколько порядков.
3. по сути заново собирается одно приложение несколько раз — на сервере и на клиенте.
4. в React метод renderToString может быть медленным из-за синхронности и однопоточности.
5. для ускорения загрузки необходимо подключать HTML кеширование / кеширование компонентов.
Для меня, как новичка в этих вопросах, пока не предоставляется возможным выбрать стратегию рендеринга в связке React-Django. Вроде если нет интерактива особого, то в CSR тоже нет смысла. Может для сайтов вроде блогов имеет смысл применить потоковый серверный рендеринг или прогрессивную регидратацию? Или вообще ничего не придумывать на стороне фронта и оставить джанговский рендеринг шаблонов? В последнем случае вообще не надо заморачиваться над фронтом и не предустанавливать кучу библиотек и не допиливать структуру джанги под rest api?
Подскажите, в чем выгода от подключения React SSR для написания а-ля блога, кроме динамичности и SEO восприимчивости?
для подобного формата существует gatsbyjs + gh-pages + firebase. Два последних названия можно изменить в зависимости от предпочтений, но gatsby, если у вас ни полмиллиона подписчиков, выкидывать не стоит. Лучше не придумаешь. Хотя есть нюансы которых лучше бы и не было...
twoone, да, стоящие батарейки, но для чистой статики. Я все таки намереваюсь хранить контент в БД и здесь не без серверной стороны. Логику для выдачи представлений я все же хочу сохранить в джанге
NextJS еще существует, если СУБД нужна
Станислав Шабалин, в том-то и дело что gatsby собирает статику из любого контента, даже хранящегося в БД. А приложение тем не мение получается обычное spa.
twoone, я не увидел чтобы можно было обращаться к mySQL.
Но мне логика нужна на сервере. Например, загрузка работ на сервер каждым зарегистрированным пользователем и тд. Выходит, что я должен выдавать на рендеринг или готовую html страницу или json, но парсить придется. Вообщем, я в затруднении: каким путем пойти для моих нужд
Станислав Шабалин, работ на сервер каждым пользователем - это уже не блог. хотя и в этом случаи зачем сервер? Почему сразу в облачную БД не грузить и её уже собирать с статику? Сейчас сервера для таких мелочей уже не используют.
twoone, но комментировать работы и ставить оценки это из области блога все же я думаю. И залить фото посетитель с правами тоже способен в блоге. Разе я не прав?
Да, участников может быть до сотни и у каждого работы (фото/описание) в разных категориях плюс комменты плюс это все за 15 лет и плюс каждый год будет контент участников добавляться. Выгодно ли облако в таком случае?
Станислав Шабалин, ну комменты, аватары и оценки это же не контент! Их то рендерить нужно уже в рантайме. До комментов вообще ещё долистать нужно! Так зачем же их рендерить то сразу?
В силу отсутствия опыта работы с React, я пока не представляю как генерируются статические страницы, если контент в БД будет обновляться и добавляться? Кто отвечает за ререндеринг статики и в какой это момент происходит? Это больше относится даже к продакшн
Pavel Shvedov, таки сам ищу аргументы за или против. Не первый раз слышу, что надо изучать Реакт даже для простых сайтов, вроде как время выкраивается и скорость написания сайтов.
Хотел было развернуть и начать использовать, но прочтение статей тормознуло.
Есть ощущение, что я замедлюсь, а не ускорюсь. )
Блог - это образно. Я буду писать сайт с портфолио участников выставок за 15 лет с возможностью оценивать работы и комментировать. Плюс поиск и фильтр по категориям и номинациям победителей.
Все это будет поддерживаться и расти. Как-то так.
Станислав Шабалин, оправдано, когда на странице статичный контент, она грузится без лишней логики (запросы к базе и к другим источникам) на сервере, и отображается в браузере без надобности выполнить кучу javascript кода, дружелюбно влияет на CEO, плюс есть инструменты, которые могут нагенерить статичных страниц.
Не нужно использовать реакт на фронте просто для того, чтоб использовать реакт, там где это избыточно. Реакт и прочие подобные инструменты оправданы когда на странице есть динамически меняющиеся данные, подгружаемые асинхронно, куча элементов на странице, которые связаны какой-то бизнес логикой, всем этим рулить проще используя библиотеки/фреймворки
Станислав Шабалин, ну вот блок с комментами можно сделать на реакте, для него не нужен ssr, пусть грузится как обычно, а для контента страницы блога это ни к чему
Pavel Shvedov, тогда тут получится миксовый вариант. И мне админка и логика Django в любом случае будет нужна. Здесь совместить придется.
От сюда следует:
1. Тот же gatsby (к примеру ) стоит сюда внедрять для статики ?
2. rest api потребуется на бэкенде, ведь придется вытаскивать контент из БД и отдавать фронту для подставления в шаблоны?
