Важное преемущество SSR, о котором здесь не говорилось - что он позволяет избежать "баунсинга" элементов с непредказуемой выстотой, например, элементов шапки, размер которых может зависеть от обьема контента или функционала кастомизации. Угадать заранее размер скелетона под такой блок может быть фактически невозможно, кроме как отрендерить уже вместе с контентом заранее на сервере.
От html перешли к php. От php перешли к node·js. В итоге вместе с фичами spa получили много проблем, кои стали решать ssr. Получается, что вернулись к парадигме серверов на php, новенький ssr, но на node·js
У нас один проект Next при 500 посетителях ложит на лопатки 4-ядерный i5. А до этого на чистом реакте работало все значительно быстрее, т.к. вся нагрузка была у пользователя.
@@VolodkaBobovich Для PHP это были бы смешные цифры. CPU интенсивные приложения, а в данном случае оно таким и будет, всегда были значительно быстрее на php.
Если вы используете Flutter для разработки веб-приложений, вам доступны оба подхода: SSR и SPA. Flutter предоставляет возможности для создания веб-приложений с помощью SPA, используя стандартный подход с одной точкой входа (single entry point) и навигацией между страницами с помощью маршрутизации.
как и просили поправляю в коментариях. при SSR в случае с интерактивной страницей загрузка будет происходить в большенстве случаев дольше и значительно нагружать сервер. при SPA скрипты и стили кешируются браузером и загружается всего 1 раз при первом открытии страницы, и рендеринг скриптом по скорости практически не отличается от рендеринга html (браузер парсит хтмл и рендерит его теми же средствами). в большенстве ситуаций страница загружается из кэша и рендерится так же быстро как html и единственное, что ждёт пользователь это данные, которые получаются с сервера максимально быстро, поскольку это единственное, что от сервера требуется. SSR даст преимущества в скорости загрузки только при страницах со статическим контентом, которые будут кэшироваться на сервере и в браузере. если при рендеринге на сервере, что ест рессурсы сервера, будут данные получаться из базы, то это добавит задержки перед получением ответа от сервера и такая страница не может кешироваться ни на сервере ни браузером и в целом будет дольше грузиться. есть вариант при котором делается клиентский SPA, а вариант для ботов делается отдельно упрощённый, с примитивным лаяутом, без стилей и без лишней информации и работает как SSR приложение.
Бред. SSR сделан для того, чтобы снять нагрузку с клиента по запуску клиентских скриптов и рендеру контента. Скрипты при SSR также можно кешировать и это не относится к SSR т.к настраивается отдельно. Страницы SSR можно кешировать (вот это да!) либо браузером через заголовки, либо сервером. Задержки перед походом в БД также можно кешировать. Разберись получше, чем писать такой бред
Данный конкретный SSR сделан для того, чтобы продавать Versel-овские сервисы. А вообще надо справшивать, не для чего он сделан, а кому он нужен. Если у вас 100 пользователей которые сидят на IBM XT, и хотят почитать газету или блог, то быстрее и проще будет рендерить на сервере. Если у вас нормальные производительные клиенты и их много, это затея так себе, особенно если приложение богато интерактивно, формочки-таблицы-бухгалтерии. Запаритесь кешировать, точнее разбираться, что кешировать, а что нет.
Остался один шаг, для того чтобы начать разрабатывать идеальные сайты - надо просто начать рендерить прямо в базе данных, и брать "хатмл" из таблицы прямым SQL запросом из реактовского хука, а все проблемы можно будет решить, конечно. Хотя зачем хатмл, можно сразу гифчик. Я вот только одного не понимаю, откуда вот эти цифры 0.3 секунды, за которые пользователь уйдет с сайта? Чтото я не видел людей, которые бросают инстаграмм или фейсбук, не дождавшись долей секунды. А лендинги надо делать на чистом хатмл, если хочется роботов, которые точно дождуться. Короче говоря, как то эта вся затея выглядит странно.
@@levinbraun3475 Ну так вот, это надо постараться написать приложение, которое в современном мире грузит и запускает первоначальный бандл 3 секунды, да еще и на рамдомного пользователя, без лендинга. Это скорее всего будет монолит, по сложности сравнимый с таблицами Excell. Короче говоря, я сильно сомневаюсь, что реализация этих вот механизмов SSR, да еще в такой кривущей и "живой" экосистеме как Реакт, имеет какую-то подобную мотивацию, о которой нам тут рассказывают.
Frontend: SPA + HTML5 History + Service Worker Backend: Express + Handlebars + DB - SEO сделаете полностью управляемым - Нет проблем с кэшем - Прозрачная работа (что даст меньше трудностей при поиске и исправлений багов) - Забыть и не вспоминать про все траблы у SSR - Легко масштабировать - Минимум нагрузки на хостинг Но есть один минус, нужно для SEO обдумать и писать вторую вёрстку где даст облегчение Handlebars но всё же доп работа - которая нужна только для SEO (но SEO сейчас далеко не везде требуется)
Там где не требуется сео как правило первый экран это логин/регистрация. А следственно там и ssr никакой не нужен, потому что весь контент находится за стеной через которую поисковые роботы не проходят, как следствие наличие чего-то кроме spa не требуется, т.к. не несет никакой смысловой нагрузки…
Разрабы: мы сделали код быстрее на N%, уменьшили трафик, добавили много функционала в веб! Бизнес: отлично, впихнем туда рекламу в неимоверном количестве чтоб загрузить трафик, тормозить рендер и похоронить желание пользователей снова заходить к нам.
Спасибо за видео. К минусам добавил бы ограничение на хранение токена авторизации только в куках. Если в начале проекта выбрали localStorage то сложновато будет переехать на ssr
@@milishnikoffofficial2905 например если страница доступна только зареганому пользователю или пользователю с pro аккаунтом, когда ты переходишь на страницу идёт get запрос который автоматически может включать только куки. Это для случая когда мы хотим юзеру сразу показать контент, без скелетонов и лоадеров
Когда юзер открывает страницу, браузер делает запрос, и нужная кука для этого домена улетает прямо в этом запросе. На стороне приложения во время SSR все эти пользовательские куки тебе доступны. Ты можешь авторизовать своего юзера и работать с ним на стороне SSR еще до того, как он загрузил(получил) страницу. @@milishnikoffofficial2905
@@deikun95 Потому что SSR каждый раз создает новую страницу на стороне сервера и данный которые лягут на страницу не смогут попасть в кэш. И за этого размер передачи данных и сборка страниц с обработкой бизнес логики сервером обойдется дороже. SPA создает bundle который ляжет в кэш и все что будет делать сервер это раздавать данные в виде json после обработки бизнес логики.
@@АлександрГерасимов-с3щ Нет, это верно, SSR имеет те же проблемы, что и PHP, они пытаються костылями их исправить ("острова", кеширование, prefetch и т.п.), но факт генерации HTML на сервере никуда не уберешь. Но на сервере проще работать с JSON, чем с HTML на базе JSON.
Привет) MPA - это multi page application. Это когда между страницами переходишь и происходит полная перезагрузка страницы SPA - это single page application. Это когда один раз страница загрузилась, а потом контент меняется только с помощью подмены блоков с помощью JS CSR - client side rendering - это когда контент отрисовывается именно на устройтве пользователя SSR - server side rendering - это когда контент отрисовывается на сервере, и уже в качестве html долетает до клиента
А можно увидеть одно и то-же приложение, написанное двумя подходами и сравнение загрузки, скорости разработки и, хотя бы, грубым подсчетом стоимости такой разработки (сколько джунов нужно, миддлов, сеньоров, архитекторов) Тогда и станет ясно. Пока выглядит так, что SSR будет хорошо работать только на простых сайтах, типа блог, магазин и т.д. А если брать большие и гибкие системы, вроде CRM, банковских ЛК, каких-то сервисов для просмотра статистики, бирж - тут все равно выигрывает клиентский рендеринг. Также, в текущей ситуации в РФ не получится просто взять, и доустановить еще больше серверов для обработки. Это тоже довольно дорого, разве есть смысл перекладывать бОльшую часть вычислений на, итак уже загруженные, серверы? Сейчас большое количество устройств может спокойно рендерить даже сложные приложения, графики и т.д. А на случай обратного у нас есть виртуализация, большое количество оптимизаций самого реакта/вью и браузеров (кроме сафари, эти ребята стоят в сторонке)
Привет :) спасибо за комментарий) По поводу больших проектов, я сделал любопытное сравнение. Я загуглил топ 10 сайтов мира по посещаемости. И там были ютубы, фейсбуки, википедии, поисковики и так далее. И проверил, кто из них возвращает контент, а кто заглушку при первой загрузке. Счет был 3 к 7, где 3 это клиентские апки, а 7 это SSR. Поэтому большие апки вполне себе пишутся на SSR :)
По-моему, очень часто та часть, где нужна сложная, существует для каких-нибудь зарегистрированных пользователей. То есть, я бы просто взял бы с Go отдал статику для поисковиков и незарегистрированных пользователей. И сделал бы нормальное SPA для второй части. Хотя, e-commerce, конечно, будет исключением, там небольшая разница между пользователями.
@@it-sin9k основной плюс это SEO для любой странички приложения, все остальное натягивание совы на глобус. Только не каждому приложению/бизнесу это нужно. Основной минус это кол-во денег которые вбухали в продвижение рендеринга на сервере (например Vercel) и теперь большинство разрабов считает что SSR нужен всем, и побольше!
@@it-sin9k как мне кажется, не совсем, по мимо обработки API запросов, нужно еще статику генерировать, на основании этих запросов(а если страниц много, и в кеш ОЗУ на сервере все шаблоны для генерации не поместились, то придется обращаться к диску ведь?). Зависит конечно от количества данных, но выглядит как х2 загрузка на процессор.
Головне не відбити нирки, поки набиваєш гульки ... Це тільки все починається з SSR vs CSR ... а потім приходить -- інкрементальний рендерінг, гібридний застосунок (коли окремі частини працюють, як SPA, а окремі з SSR-ом), локалізація, потім ще туди прилєтає API, потом ... "а давайте наші url-rewrite-и перенесемо на nextjs" ... а потім, починається інтеграції с "безголовими CMS", сервисами авторизація та ідентифікації і т.п. З рештою це все перетворюється на "велику кулю бруду", з великою кількістю третє-партійних пакетів, що працюють якимось дуже магічним чином ... не те, що б, це все було пагано -- просто не робіть все і сразу, і по мільйону разів думайте перед тим, чи треба, чи ні, і чи можна впоратися власними силами
Не понимаю, почему многие говорят гидРАТАция, хотя написано гидРАция. По идее это два разных слова, хотя вообще не совсем понимаю как эти слова пришли в программирование. Изначально это химические термины: гидрирование это процесс присоединения водорода, гидратирование процесс присоединения молекулы воды
@@gishofeewka Ну на самом деле вопрос точной и ясной терминологии очень важен в программировании :D Это как с названиями переменных, довольно важная часть ясного, читаемого и непротиворечивого кода.
нужно добавить, что у автора, взляд на spa такойже оригинальный как и на ssr. Если говорить академическим языком - то автор практически НИЧЕГО НЕ ПОНИМАЕТ в обоих технологиях и выдает свои фантазии за то что следует освятить в видео. Есть ли в єтом что-то плохое? Наверное нет. Кроме того, что зрителям следует помнить - сказанное выше следует воспринимать как внутренний мир автора, но не как то что есть на самом деле.
Добавляем еще отложенную гидрацию, и получаем лютый трэш уже для пользователя, когда от тычет в кнопки, а ничего не работает. Итого, в попытке угодить ботам и СЕО получаем какашку. Так что если наш сайт не входит в ТОП-1000, где обязательно надо новую технологию заюзать, то стоит трыжды подумать, может лучше все же обычний SPA или даже классический сайт в стиле PHP...
как и просили поправляю в коментариях. при SSR в случае с интерактивной страницей загрузка будет происходить в большенстве случаев дольше и значительно нагружать сервер. при SPA скрипты и стили кешируются браузером и загружается всего 1 раз при первом открытии страницы, и рендеринг скриптом по скорости практически не отличается от рендеринга html (браузер парсит хтмл и рендерит его теми же средствами). в большенстве ситуаций страница загружается из кэша и рендерится так же быстро как html и единственное, что ждёт пользователь это данные, которые получаются с сервера максимально быстро, поскольку это единственное, что от сервера требуется. SSR даст преимущества в скорости загрузки только при страницах со статическим контентом, которые будут кэшироваться на сервере и в браузере. если при рендеринге на сервере, что ест рессурсы сервера, будут данные получаться из базы, то это добавит задержки перед получением ответа от сервера и такая страница не может кешироваться ни на сервере ни браузером и в целом будет дольше грузиться. есть вариант при котором делается клиентский SPA, а вариант для ботов делается отдельно упрощённый, с примитивным лаяутом, без стилей и без лишней информации и работает как SSR приложение.
Добавлю, по поводу медленной загрузки, для этого в Квик придумали специальный костыль, гидратировать компонент на ховер мыши. Реакт скоро догонит, будьте уверены, и тогда будем ловить баги не только на загрузке, но и на движениях мышкой.
@@toni4i696а какие минусы у этого? Если всю логику с редактировать перенести а клиент, то останется ли какое-то преимущество от SSR? Статических страниц, как правило, не там много у сайта.
Неплохо, но хотелось бы сразу разделить кейсы где нужен ssg для отрисовки контента и базового seo, а где ssr для персонализированной выдачи контента с запросами на сервере, тк цели и реализации у этих кейсов заметно отличаются
Я бы добавил в защиту SSR. Как в случае с Next, у вас есть полноценный сервер, где вы можете работать с запросами ответами, работать с нодой. Так же предлагается удобный встроенный API. Удобная маршрутизация с коробки и ничего отдельными пакетами не нужно лепить. Redux на сервере юзать кощунство, если вы поначалу подумаете, что это хорошая идея, то позже копнув глубже, поймете, что это не имеет смысла. Удобно делать защищенные маршруты, когда сервер принимает решение куда вас редиректить. SEO это пожалуй одна из малозначимых плюсов в SSR. Ну и можно билдить статику, если есть такая необходимость.
@@ТарасБорсук-щ2р Я лично использую RTK на клиенте, как по мне он довольно удобный при правильно организованной структуре. Еще Next сообщество рекомендуют Effector. Я попробовал, удобная вещь, но в крупном проекте не решился использовать.
Почему-то никто не упоминает что сервер имеет свойство тормозить и падать на спайках нагруки, например, особенно если хреново оптимизирован (но не только) А SPA к вашему RPM не так чувствителен
Теоретически все проблемы можно решить, а на практике перенос клиентской логики на сервер в сотни раз увеличит нагрузку на сервера и в несколько раз увеличит стоимость разработки. Next.js хорош только для SSG для Гугла, для людей он плох.
Все говорят что SSR нужен в первую очередь для SEO оптимизации, но сколько известно, все современные поисковые роботы умеют отлично работать и с SPA, так неужели нам действительно нужен SSR? Сколько не искал, не смог найти каких либо рейтингов, сравнений или чего бы то еще, что показывало бы, что сср - бро, а спа - не бро в плане сео
Тут есть несколько технических нюансов: - Один исторический. Раньше вообще поисковики не умели работать с JS и не индексировало страницу - Сейчас же они индексируют, НО они не знают, когда контент всей вашей страницы полностью загрузился. Сколько им нужно подождать прежде чем сканировать. У вас может загрузиться бандл, а потом показаться loader глобальный, а потом отобразиться статья, а паралельно будет грузиться пользователь и комментарии к статье. В итоге, что именно синдексирует поисковик непонятно. Да и про метрику, времени до первого взаимодействия когда он поставит, то же непонятно. Поэтому это крайне рискованно
Еще один минус SSR - это доп ресурсы. Вам нужен еще один сервер на ноде который будет обрабатывать запросы. Архитектура системы усложняется на еще один компонент. +расходы: вам надо дополнительно выделить бюджет на оплату этого сервера либо расширить ваши текущие ресурсы, что бы не потерять в производительности системы.
В spa есть возможность отделить экран загрузки и вшить в страницу, пользователь увидит его фактически мгновенно(по получению страницы), ещё до начала скачивания скриптов, стилей и т.д. Такой возможности в SSR нету, придется подождать рендера на сервере
Ну это дело такое. А что это будет за лодер? А не будет ли ситуации, что грузится этот лоадер, потом страница уже собралась и там layout появился + loader. Или вообще заменился на контекстный лоадер, тогда пользователь увидит их несколько, что не очень хорошая практика
@@it-sin9k Ваш пример кажется очень надуманным. Вы как разработчик полностью контролируете этот процесс и если у вас идут контекстные лоадеры, вы пероначальный просто скроете по маунту страницы, четко имея представление, что там сейчас происходит. Есть состояние страницы, состояние DOM-дерева и состояния компонентов. И я не очень понимаю вашу скептику "Ну это дело такое" . SSR в разы сложнее в организации и все ради как раз быстрой отрисовки, хотя разница в скорости и минимальна (вопрос SEO я не затрагиаю). С подходом отдельного-Inline лоадера на SPA у вас без шансов первая отрисовка будет быстрее(сам лоадер), хот ьмини угру туда вшейте на ~3кб, бользоатель все равно ее увидит быстрее чем сборку страницу на SSR, просто из-за того, что она технически попадет на жкран быстрее и пропарсится браузером быстрее, чем сборка всей страницы на сервере.
@@gishofeewka ага, а еще ангулЯр, ява и яваскрипт, хреф и хетемеель. А потом жалуются что никто не понимает. Ох уж эти филологи, навыдумыввали. Это все равно что говорить ватулка и стукен вместо бутылка и стакан, что тут иронизировать, плакать надо.
Что то я не совсем понял. SPA ведь это общее обозначение всех одностраничных сайтов. в то время как они могут быть и CSR, и SSR и SSG 4:35 но ведь сам тег скрипта и размещают в конце html кода, чтобы джс начал грузится когда 99% страницы уже отображается. то есть страница пустой не будет
@@it-sin9k ладно, я наверно чушь сказал. просто всегда думал spa это сайт использующий один html документ. в то время как ssr, способ рендеринга этого документа на сервере.
@@it-sin9k может. например главная страница сайта тяжелая, и её проще и быстрее построить на сервере, затем уже инициализировать SPA после загрузки всех скриптов и делать роутинг на клиенте. так например некоторые микрофронты построенны
SPA - Single Page Application - называется так не потому что он "одностраничный" с точки зрения пользователя, а потому что HTML документ только один, а роуты страниц симулируются с помощью JS
Важное преемущество SSR, о котором здесь не говорилось - что он позволяет избежать "баунсинга" элементов с непредказуемой выстотой, например, элементов шапки, размер которых может зависеть от обьема контента или функционала кастомизации. Угадать заранее размер скелетона под такой блок может быть фактически невозможно, кроме как отрендерить уже вместе с контентом заранее на сервере.
Отличное видео! Думаю, можно было еще рассказать про SSG с hydration, как в Gatsby или Astro
От html перешли к php.
От php перешли к node·js.
В итоге вместе с фичами spa получили много проблем, кои стали решать ssr.
Получается, что вернулись к парадигме серверов на php, новенький ssr, но на node·js
ну не совсем, мы пришли к миксу, всё таки полный SSR это очень большая нагрузка на сервер, ну а полный CSR это слишком медленный TTI
PHP TOP
У нас один проект Next при 500 посетителях ложит на лопатки 4-ядерный i5. А до этого на чистом реакте работало все значительно быстрее, т.к. вся нагрузка была у пользователя.
@@VolodkaBobovich Для PHP это были бы смешные цифры. CPU интенсивные приложения, а в данном случае оно таким и будет, всегда были значительно быстрее на php.
Если вы используете Flutter для разработки веб-приложений, вам доступны оба подхода: SSR и SPA. Flutter предоставляет возможности для создания веб-приложений с помощью SPA, используя стандартный подход с одной точкой входа (single entry point) и навигацией между страницами с помощью маршрутизации.
Интересно было бы кстати узнать как работает redux в ssr и как происходит гидратация если на сервере тоже есть redux wrapper
JS продолжают пытаться пере изобрести PHP)
Спасибо, ваше объяснение как раз дополнило картинку в голове 😊
как и просили поправляю в коментариях. при SSR в случае с интерактивной страницей загрузка будет происходить в большенстве случаев дольше и значительно нагружать сервер. при SPA скрипты и стили кешируются браузером и загружается всего 1 раз при первом открытии страницы, и рендеринг скриптом по скорости практически не отличается от рендеринга html (браузер парсит хтмл и рендерит его теми же средствами). в большенстве ситуаций страница загружается из кэша и рендерится так же быстро как html и единственное, что ждёт пользователь это данные, которые получаются с сервера максимально быстро, поскольку это единственное, что от сервера требуется. SSR даст преимущества в скорости загрузки только при страницах со статическим контентом, которые будут кэшироваться на сервере и в браузере. если при рендеринге на сервере, что ест рессурсы сервера, будут данные получаться из базы, то это добавит задержки перед получением ответа от сервера и такая страница не может кешироваться ни на сервере ни браузером и в целом будет дольше грузиться. есть вариант при котором делается клиентский SPA, а вариант для ботов делается отдельно упрощённый, с примитивным лаяутом, без стилей и без лишней информации и работает как SSR приложение.
Бред.
SSR сделан для того, чтобы снять нагрузку с клиента по запуску клиентских скриптов и рендеру контента.
Скрипты при SSR также можно кешировать и это не относится к SSR т.к настраивается отдельно.
Страницы SSR можно кешировать (вот это да!) либо браузером через заголовки, либо сервером.
Задержки перед походом в БД также можно кешировать.
Разберись получше, чем писать такой бред
Данный конкретный SSR сделан для того, чтобы продавать Versel-овские сервисы. А вообще надо справшивать, не для чего он сделан, а кому он нужен. Если у вас 100 пользователей которые сидят на IBM XT, и хотят почитать газету или блог, то быстрее и проще будет рендерить на сервере. Если у вас нормальные производительные клиенты и их много, это затея так себе, особенно если приложение богато интерактивно, формочки-таблицы-бухгалтерии. Запаритесь кешировать, точнее разбираться, что кешировать, а что нет.
Остался один шаг, для того чтобы начать разрабатывать идеальные сайты - надо просто начать рендерить прямо в базе данных, и брать "хатмл" из таблицы прямым SQL запросом из реактовского хука, а все проблемы можно будет решить, конечно. Хотя зачем хатмл, можно сразу гифчик. Я вот только одного не понимаю, откуда вот эти цифры 0.3 секунды, за которые пользователь уйдет с сайта? Чтото я не видел людей, которые бросают инстаграмм или фейсбук, не дождавшись долей секунды. А лендинги надо делать на чистом хатмл, если хочется роботов, которые точно дождуться. Короче говоря, как то эта вся затея выглядит странно.
корректная статистика это 3 секунды. Автор видимо ошибся
@@levinbraun3475 Ну так вот, это надо постараться написать приложение, которое в современном мире грузит и запускает первоначальный бандл 3 секунды, да еще и на рамдомного пользователя, без лендинга. Это скорее всего будет монолит, по сложности сравнимый с таблицами Excell. Короче говоря, я сильно сомневаюсь, что реализация этих вот механизмов SSR, да еще в такой кривущей и "живой" экосистеме как Реакт, имеет какую-то подобную мотивацию, о которой нам тут рассказывают.
Все по теме, доступно, понятно.) Спасибо!
Frontend: SPA + HTML5 History + Service Worker
Backend: Express + Handlebars + DB
- SEO сделаете полностью управляемым
- Нет проблем с кэшем
- Прозрачная работа (что даст меньше трудностей при поиске и исправлений багов)
- Забыть и не вспоминать про все траблы у SSR
- Легко масштабировать
- Минимум нагрузки на хостинг
Но есть один минус, нужно для SEO обдумать и писать вторую вёрстку где даст облегчение Handlebars но всё же доп работа - которая нужна только для SEO (но SEO сейчас далеко не везде требуется)
Там где не требуется сео как правило первый экран это логин/регистрация. А следственно там и ssr никакой не нужен, потому что весь контент находится за стеной через которую поисковые роботы не проходят, как следствие наличие чего-то кроме spa не требуется, т.к. не несет никакой смысловой нагрузки…
Разрабы: мы сделали код быстрее на N%, уменьшили трафик, добавили много функционала в веб!
Бизнес: отлично, впихнем туда рекламу в неимоверном количестве чтоб загрузить трафик, тормозить рендер и похоронить желание пользователей снова заходить к нам.
Хорошо сказано)
Спасибо за видео. К минусам добавил бы ограничение на хранение токена авторизации только в куках. Если в начале проекта выбрали localStorage то сложновато будет переехать на ssr
не понял , куки тоже в браузере , какая разница localStorage или cookie?
@@milishnikoffofficial2905 например если страница доступна только зареганому пользователю или пользователю с pro аккаунтом, когда ты переходишь на страницу идёт get запрос который автоматически может включать только куки. Это для случая когда мы хотим юзеру сразу показать контент, без скелетонов и лоадеров
Когда юзер открывает страницу, браузер делает запрос, и нужная кука для этого домена улетает прямо в этом запросе. На стороне приложения во время SSR все эти пользовательские куки тебе доступны. Ты можешь авторизовать своего юзера и работать с ним на стороне SSR еще до того, как он загрузил(получил) страницу.
@@milishnikoffofficial2905
@@milishnikoffofficial2905 куки доступны и на сервере (при getServerSideProps в nextjs) и на клиент, а localStorage только на клиенте
Забыли сказать, что SSR делает сервера намного дороже. Также SSR не гибко кеширует данные и удлиняет вторую и последующие загрузки в сравнении с SPA.
+ по защите от атак сложно, на апи можно рейт поставить + кэш на спа, а вот на ssr даже страшно подумать
Это почему намного дороже?
@@deikun95 Потому что SSR каждый раз создает новую страницу на стороне сервера и данный которые лягут на страницу не смогут попасть в кэш. И за этого размер передачи данных и сборка страниц с обработкой бизнес логики сервером обойдется дороже. SPA создает bundle который ляжет в кэш и все что будет делать сервер это раздавать данные в виде json после обработки бизнес логики.
@@DymDima это не верно. Не надо путать SSR SPA с классическими многостраничными сайтами на PHP.
@@АлександрГерасимов-с3щ Нет, это верно, SSR имеет те же проблемы, что и PHP, они пытаються костылями их исправить ("острова", кеширование, prefetch и т.п.), но факт генерации HTML на сервере никуда не уберешь. Но на сервере проще работать с JSON, чем с HTML на базе JSON.
Синяк ты просто бомба !
Создавая новый проект для SPA только, можно ли использовать next?
к сожалению я не вижу таких опций. Есть шансы что react-router-v7 запилит вариант, как можно на нем как SPA обычный делать, так и SSR
Ну всё, поехали на бэк
Спасибо за контент. Есть вопрос, что значат и чем отличаются термины как MPA, SPA от CSR и SSR
Привет)
MPA - это multi page application. Это когда между страницами переходишь и происходит полная перезагрузка страницы
SPA - это single page application. Это когда один раз страница загрузилась, а потом контент меняется только с помощью подмены блоков с помощью JS
CSR - client side rendering - это когда контент отрисовывается именно на устройтве пользователя
SSR - server side rendering - это когда контент отрисовывается на сервере, и уже в качестве html долетает до клиента
А можно увидеть одно и то-же приложение, написанное двумя подходами и сравнение загрузки, скорости разработки и, хотя бы, грубым подсчетом стоимости такой разработки (сколько джунов нужно, миддлов, сеньоров, архитекторов)
Тогда и станет ясно. Пока выглядит так, что SSR будет хорошо работать только на простых сайтах, типа блог, магазин и т.д.
А если брать большие и гибкие системы, вроде CRM, банковских ЛК, каких-то сервисов для просмотра статистики, бирж - тут все равно выигрывает клиентский рендеринг.
Также, в текущей ситуации в РФ не получится просто взять, и доустановить еще больше серверов для обработки. Это тоже довольно дорого, разве есть смысл перекладывать бОльшую часть вычислений на, итак уже загруженные, серверы? Сейчас большое количество устройств может спокойно рендерить даже сложные приложения, графики и т.д. А на случай обратного у нас есть виртуализация, большое количество оптимизаций самого реакта/вью и браузеров (кроме сафари, эти ребята стоят в сторонке)
Привет :) спасибо за комментарий)
По поводу больших проектов, я сделал любопытное сравнение. Я загуглил топ 10 сайтов мира по посещаемости. И там были ютубы, фейсбуки, википедии, поисковики и так далее. И проверил, кто из них возвращает контент, а кто заглушку при первой загрузке. Счет был 3 к 7, где 3 это клиентские апки, а 7 это SSR. Поэтому большие апки вполне себе пишутся на SSR :)
Еще можно по возможности использовать next export, чтобы не тратить серверное время на сборку html на лету.
Да, но там есть проблемы с динамическим роутингом
@@it-sin9k В принципе getStaticPath большенство задач решает. А вот с часто добавляемым контентом плохо каждый раз билд делать.
По-моему, очень часто та часть, где нужна сложная, существует для каких-нибудь зарегистрированных пользователей.
То есть, я бы просто взял бы с Go отдал статику для поисковиков и незарегистрированных пользователей.
И сделал бы нормальное SPA для второй части.
Хотя, e-commerce, конечно, будет исключением, там небольшая разница между пользователями.
Похоже больше на рекламу next, одни прямо плюсы
ну почему же) сложнее разрабатывать такой продукт основной минус
@@it-sin9k основной плюс это SEO для любой странички приложения, все остальное натягивание совы на глобус.
Только не каждому приложению/бизнесу это нужно. Основной минус это кол-во денег которые вбухали в продвижение рендеринга на сервере (например Vercel) и теперь большинство разрабов считает что SSR нужен всем, и побольше!
По-моему, наоборот, одни минусы. Прямо в видео.
Что будет с сервером, на котором крутится SSR, при наплыве большого количества пользователей?
тоже самое, что и с сервером, который обрабатывает все API запросы)
@@it-sin9kне совсем, так как запросы может обрабатывать нормальный сервер на Go.
@@it-sin9k как мне кажется, не совсем, по мимо обработки API запросов, нужно еще статику генерировать, на основании этих запросов(а если страниц много, и в кеш ОЗУ на сервере все шаблоны для генерации не поместились, то придется обращаться к диску ведь?). Зависит конечно от количества данных, но выглядит как х2 загрузка на процессор.
seo оптимизация на ssr это боль
топ
Головне не відбити нирки, поки набиваєш гульки ...
Це тільки все починається з SSR vs CSR ... а потім приходить -- інкрементальний рендерінг, гібридний застосунок (коли окремі частини працюють, як SPA, а окремі з SSR-ом), локалізація, потім ще туди прилєтає API, потом ... "а давайте наші url-rewrite-и перенесемо на nextjs" ... а потім, починається інтеграції с "безголовими CMS", сервисами авторизація та ідентифікації і т.п. З рештою це все перетворюється на "велику кулю бруду", з великою кількістю третє-партійних пакетів, що працюють якимось дуже магічним чином ...
не те, що б, це все було пагано -- просто не робіть все і сразу, і по мільйону разів думайте перед тим, чи треба, чи ні, і чи можна впоратися власними силами
Не понимаю, почему многие говорят гидРАТАция, хотя написано гидРАция. По идее это два разных слова, хотя вообще не совсем понимаю как эти слова пришли в программирование. Изначально это химические термины: гидрирование это процесс присоединения водорода, гидратирование процесс присоединения молекулы воды
hydration переводится как гидратация, а не гидрация
Филологи снова врываются в айти 😂 именно этот коммент я и хотел увидеть при обсуждении SSR
@@gishofeewka Ну на самом деле вопрос точной и ясной терминологии очень важен в программировании :D Это как с названиями переменных, довольно важная часть ясного, читаемого и непротиворечивого кода.
@@vladislavkuleshov7248 если это правда, то я дебил. Извините меня
нужно добавить, что у автора, взляд на spa такойже оригинальный как и на ssr.
Если говорить академическим языком - то автор практически НИЧЕГО НЕ ПОНИМАЕТ в обоих технологиях и выдает свои фантазии за то что следует освятить в видео.
Есть ли в єтом что-то плохое? Наверное нет. Кроме того, что зрителям следует помнить - сказанное выше следует воспринимать как внутренний мир автора, но не как то что есть на самом деле.
если есть желание добавить немного конкретики, был бы очень признаетелен :)
давай уже білоруською!
Добавляем еще отложенную гидрацию, и получаем лютый трэш уже для пользователя, когда от тычет в кнопки, а ничего не работает. Итого, в попытке угодить ботам и СЕО получаем какашку. Так что если наш сайт не входит в ТОП-1000, где обязательно надо новую технологию заюзать, то стоит трыжды подумать, может лучше все же обычний SPA или даже классический сайт в стиле PHP...
Есть такая проблема)
как и просили поправляю в коментариях. при SSR в случае с интерактивной страницей загрузка будет происходить в большенстве случаев дольше и значительно нагружать сервер. при SPA скрипты и стили кешируются браузером и загружается всего 1 раз при первом открытии страницы, и рендеринг скриптом по скорости практически не отличается от рендеринга html (браузер парсит хтмл и рендерит его теми же средствами). в большенстве ситуаций страница загружается из кэша и рендерится так же быстро как html и единственное, что ждёт пользователь это данные, которые получаются с сервера максимально быстро, поскольку это единственное, что от сервера требуется. SSR даст преимущества в скорости загрузки только при страницах со статическим контентом, которые будут кэшироваться на сервере и в браузере. если при рендеринге на сервере, что ест рессурсы сервера, будут данные получаться из базы, то это добавит задержки перед получением ответа от сервера и такая страница не может кешироваться ни на сервере ни браузером и в целом будет дольше грузиться. есть вариант при котором делается клиентский SPA, а вариант для ботов делается отдельно упрощённый, с примитивным лаяутом, без стилей и без лишней информации и работает как SSR приложение.
Добавлю, по поводу медленной загрузки, для этого в Квик придумали специальный костыль, гидратировать компонент на ховер мыши. Реакт скоро догонит, будьте уверены, и тогда будем ловить баги не только на загрузке, но и на движениях мышкой.
Спасибо, как раз сегодня собирался разобраться в этой теме, и наткнулся на видео. 👍👍
Perfect match!
redux, будет только на клиенте работать ) но есть next-redux-wrapper, который позволяет использовать redux с ssr )
О, прикольно, спасибо за инфу, а не тестил как он работает?
@@semyon3100 я годик назад работал с этим, вроде норм работало ) Там чуть геморно подключать его )
Хм, а я думал будет и весь синхронный код исполнится.
Не стоит этого делать, как правило это не нужно
@@toni4i696а какие минусы у этого? Если всю логику с редактировать перенести а клиент, то останется ли какое-то преимущество от SSR? Статических страниц, как правило, не там много у сайта.
Неплохо, но хотелось бы сразу разделить кейсы где нужен ssg для отрисовки контента и базового seo, а где ssr для персонализированной выдачи контента с запросами на сервере, тк цели и реализации у этих кейсов заметно отличаются
Постараюсь вдаться в тему глубже в будущих видео)
Я бы добавил в защиту SSR. Как в случае с Next, у вас есть полноценный сервер, где вы можете работать с запросами ответами, работать с нодой. Так же предлагается удобный встроенный API. Удобная маршрутизация с коробки и ничего отдельными пакетами не нужно лепить. Redux на сервере юзать кощунство, если вы поначалу подумаете, что это хорошая идея, то позже копнув глубже, поймете, что это не имеет смысла. Удобно делать защищенные маршруты, когда сервер принимает решение куда вас редиректить. SEO это пожалуй одна из малозначимых плюсов в SSR. Ну и можно билдить статику, если есть такая необходимость.
Спасибо за развернутый комментарий!)
Что использовать вместо Redux?
@@ТарасБорсук-щ2р Я лично использую RTK на клиенте, как по мне он довольно удобный при правильно организованной структуре. Еще Next сообщество рекомендуют Effector. Я попробовал, удобная вещь, но в крупном проекте не решился использовать.
Хотим больше контента про Next js!)
Почему-то никто не упоминает что сервер имеет свойство тормозить и падать на спайках нагруки, например, особенно если хреново оптимизирован (но не только)
А SPA к вашему RPM не так чувствителен
Вероятно исходим обычно из того, что эта проблема решаемая)
Теоретически все проблемы можно решить, а на практике перенос клиентской логики на сервер в сотни раз увеличит нагрузку на сервера и в несколько раз увеличит стоимость разработки. Next.js хорош только для SSG для Гугла, для людей он плох.
@@it-sin9k Если у тебя бесконечно большой собственный дата-центр, за который не нужно ПЛАТИТЬ, то да, решаемая)
Все говорят что SSR нужен в первую очередь для SEO оптимизации, но сколько известно, все современные поисковые роботы умеют отлично работать и с SPA, так неужели нам действительно нужен SSR? Сколько не искал, не смог найти каких либо рейтингов, сравнений или чего бы то еще, что показывало бы, что сср - бро, а спа - не бро в плане сео
Есть личный опыт - spa индексируется ботами, но значительно хуже
Тут есть несколько технических нюансов:
- Один исторический. Раньше вообще поисковики не умели работать с JS и не индексировало страницу
- Сейчас же они индексируют, НО они не знают, когда контент всей вашей страницы полностью загрузился. Сколько им нужно подождать прежде чем сканировать. У вас может загрузиться бандл, а потом показаться loader глобальный, а потом отобразиться статья, а паралельно будет грузиться пользователь и комментарии к статье. В итоге, что именно синдексирует поисковик непонятно. Да и про метрику, времени до первого взаимодействия когда он поставит, то же непонятно. Поэтому это крайне рискованно
В действительности костыль в виде SSR не нужен
Спасибо автору, замечательный контент!
Еще один минус SSR - это доп ресурсы.
Вам нужен еще один сервер на ноде который будет обрабатывать запросы. Архитектура системы усложняется на еще один компонент.
+расходы: вам надо дополнительно выделить бюджет на оплату этого сервера либо расширить ваши текущие ресурсы, что бы не потерять в производительности системы.
Да) сложнее код, дороже проект) полностью согласен, но и стараются дать что то в ответ
В spa есть возможность отделить экран загрузки и вшить в страницу, пользователь увидит его фактически мгновенно(по получению страницы), ещё до начала скачивания скриптов, стилей и т.д.
Такой возможности в SSR нету, придется подождать рендера на сервере
Ну это дело такое. А что это будет за лодер? А не будет ли ситуации, что грузится этот лоадер, потом страница уже собралась и там layout появился + loader. Или вообще заменился на контекстный лоадер, тогда пользователь увидит их несколько, что не очень хорошая практика
@@it-sin9k
Ваш пример кажется очень надуманным.
Вы как разработчик полностью контролируете этот процесс и если у вас идут контекстные лоадеры, вы пероначальный просто скроете по маунту страницы, четко имея представление, что там сейчас происходит. Есть состояние страницы, состояние DOM-дерева и состояния компонентов.
И я не очень понимаю вашу скептику "Ну это дело такое" . SSR в разы сложнее в организации и все ради как раз быстрой отрисовки, хотя разница в скорости и минимальна (вопрос SEO я не затрагиаю). С подходом отдельного-Inline лоадера на SPA у вас без шансов первая отрисовка будет быстрее(сам лоадер), хот ьмини угру туда вшейте на ~3кб, бользоатель все равно ее увидит быстрее чем сборку страницу на SSR, просто из-за того, что она технически попадет на жкран быстрее и пропарсится браузером быстрее, чем сборка всей страницы на сервере.
да давайте по Некст жс
Очень спорно что SSR быстрее.
почему?) следующее видео как раз будет показывать почему)
не цэсэс, а сиэсэс боже как режет слух
О господи, поправляйтесь 🙏
Ещё один филолог рвётся, а ну быстро говорите правильно! А иначе непонятно человеку про что речь 😁
Да уж, я думал всем очевидно, что правильно каэсэс😁
@@gishofeewka ага, а еще ангулЯр, ява и яваскрипт, хреф и хетемеель. А потом жалуются что никто не понимает. Ох уж эти филологи, навыдумыввали. Это все равно что говорить ватулка и стукен вместо бутылка и стакан, что тут иронизировать, плакать надо.
@@golden_smiles Вы не поняли о чем говорил автор в видео?
Что то я не совсем понял. SPA ведь это общее обозначение всех одностраничных сайтов. в то время как они могут быть и CSR, и SSR и SSG
4:35 но ведь сам тег скрипта и размещают в конце html кода, чтобы джс начал грузится когда 99% страницы уже отображается. то есть страница пустой не будет
А как SPA может быть SSR?
По поводу JS файлов, я показывал скриншот, они там не то чтобы в конце, они в середине head секции
@@it-sin9k ладно, я наверно чушь сказал. просто всегда думал spa это сайт использующий один html документ. в то время как ssr, способ рендеринга этого документа на сервере.
@@it-sin9k может. например главная страница сайта тяжелая, и её проще и быстрее построить на сервере, затем уже инициализировать SPA после загрузки всех скриптов и делать роутинг на клиенте. так например некоторые микрофронты построенны
SPA - Single Page Application - называется так не потому что он "одностраничный" с точки зрения пользователя, а потому что HTML документ только один, а роуты страниц симулируются с помощью JS