fullstack-development
Выпилить SSR
SSR значительно усложняет инициализацию приложения, его архитектуру и разработку.
Учитывая что целевым сегментом с нашей архитектурой и стеком являются сложные приложения автоматизирующие бизнес-процессы, SEO самих приложений редко имеет смысл, а проиндексировать можно и лендинг который можно отдельно раздавать отрендеренным.
Скорость загрузки также неактуальна. Через code splitting всё весьма быстро работать будет.
Предлагаю выпилить весь относящийся к SSR код.
Если я что-то упускаю - объясните пожалуйста.
Да, в этом что-то есть. На большинстве проектов SSR не нужен, поэтому имеет смысл его выпилить, но оставить где-то ветку с полностью настроенным и пригодным к употреблению SSR.
Возможно стоит обсуждать этот момент на старте с заказчиками, типа есть 3 варианта:
- мы на старте настраиваем SSR (копируем всё из ветки с SSR) и постоянно в ходе разработки поддерживаем его в рабочем состоянии. Поломать SSR вообще изи, поэтому нужно за этим следить. Нужно немного времени на настройку + разработка местами втыкается в разруливание особенностей SSR.
- мы полностью отказываемся от SSR. Можно изначально клиенту отдавать красивый экран с прелоадером, фоном загружаются наши скрипты и стартует SPA приложение, скорость первой загрузки, как уже сказал Серега, мы можем оптимизировать с помощью асинхронных фич. Тут никаких затрат по времени нет.
- мы на старте отказываемся от SSR, но после старта MVP мы планируем его настроить. Тут нужно сразу предупредить заказчика (!), что поздняя настройка SSR может занять много времени, т.к. все особенности SSR будут разруливаться разом, а не по мере поступления в ходе разработки.
Ещё есть вариант с использованием сервисов по пререндеру https://habr.com/ru/post/418619/ https://habr.com/ru/company/renderjs/blog/327612/ Кто-нибудь изучал/пробовал?
Кстати да, есть еще вариант юзать prerender-spa-plugin, вставляешь его в вебпак конфиг и получаешь отрисованные странички. Но это как бы не совсем SSR, сервера нет и мы не можем динамическое что-то воткнуть в странички.
Я изучал темы по пререндеру около 3-х лет назад, все было плохо и поисковики в итоге херовато с ними работали.
Мне кажется, что SSR тут не надо выпиливать потому что он заствляет все вносимые в starter-kit свистопердерелки учитывать SSR, а значит, что все используемые здесь подходы не только подтвердили, что их можно подключить с имеющимся SSR, но и сразу примеры такого подключения.
Я изучал темы по пререндеру около 3-х лет назад, все было плохо и поисковики в итоге херовато с ними работали.
3 года это достаточно большой срок чтобы продвинуться. Возможно стоит снова изучить
Мне кажется, что SSR тут не надо выпиливать потому что он заствляет все вносимые в starter-kit свистопердерелки учитывать SSR, а значит, что все используемые здесь подходы не только подтвердили, что их можно подключить с имеющимся SSR, но и сразу примеры такого подключения.
То, что можно накидать костылей в несколько слоев - не значит что мы движемся в верном направлении. Я не работал сам с SSR, но слушал рассуждения на собеседовании где ребята долго обсуждали какимии хаками они решали ту или иную проблему и всё это довольно грустно звучало, совершенно не хотелось бы с таким работать. Причём ломается на любой чих, судя по ПР с выпилом jss
Ну на самом деле ты преувеличиваешь :) То, что JSS не приспособлен к SSR как раз пример сложной проблемы, когда вроде все в начале работает, но под хорошими объемами начинает лагать. Там кстати и на клиентской стороне стили лагали те вроде бы, так что там не стольо SSR виноват, сколько лагучесть рантайма JSS с кучей динамических значений. Хаки там далеко не везде, большинство задач вполне нормально решаются, просто их надо учитывать. Хак я вспоминаю только с ожиданием саг.
@Znack что по поводу самого смысла использования SSR? На проектах, где я был он не нужен был. Кому вообща нужна индексация поисковиками, если мы создаём SPA по автоматизации бизнес-процессов, а не публикации контента, который важно индексировать?
Ну на самом деле ты преувеличиваешь :) То, что JSS не приспособлен к SSR как раз пример сложной проблемы, когда вроде все в начале работает, но под хорошими объемами начинает лагать. Там кстати и на клиентской стороне стили лагали те вроде бы, так что там не стольо SSR виноват, сколько лагучесть рантайма JSS с кучей динамических значений. Хаки там далеко не везде, большинство задач вполне нормально решаются, просто их надо учитывать. Хак я вспоминаю только с ожиданием саг.
Тут немного не соглашусь.
Когда ты пишешь для ssr, нужно помнить довольно много ограничений и закрывать их костылями, которыми в итоге обрастаешь с завидной скоростью :)
Про jss и ssr.
Там проблема была не в лагучести рантайма, а в кривой реализации самого JSS, который при рендере на сервере и на клиенте по разному инкременил имена классов.
А причина лагов была иной и можно было написать с применением jss, но без лагов (ну почти без них). Просто то что везде выставляется как преимущество jss, в итоге оказалось самым слабым местом (это я про динамические стили от пропсов).
По поводу костылей можно пообщаться с @DYAPIK , он в свое время адаптировал даталайт под SSR, и помимо затыка с jss, на сколько я помню, было много разного.