Профдеформация видимо... Слишком часто натыкаюсь на статьи формата "React VS Next, что лучше". Часто не понимают почему такое сравнение бред (уровня git VS github) и зачем вообще все эти нагромождения, вот и перестал воспринимать это по-умолчанию как сарказм и шутки 😬
Как они взаимодействуют с основным сервером? Версель как-то детектит, что в проекте есть использование edge рантаймов и начинает перенаправлять запросы туда вместо прямых запросов на сервер? Все запросы или не все? А сколько под проект выделить точек в своей network (и где) версель сам решает по метрикам проекта?
Тут вопросы про CDN в целом. Не стал особо затрагивать тему, так как хотел базовую статью про отличительные особенности именно для фронтендеров. Сам Vercel использует edge рантайм вообще для всех приложений и всех запросов. То есть вы подключили домен и Vercel сразу сказал, что этот домен лежит ещё и на этих вот точках по миру. В следующий раз, когда пользователь зайдёт на страницу - провайдер пойдёт спрашивать, а где этот домен лежит, ему в ответе прилетят доступные места и он выберет ближайшую и пойдёт на неё.
На этих точках всегда лежит логика кеширования, также, если в проекте есть реврайты, редиректы, middleware или сегменты в edge рантайме - после сборки он отправит это всё на edge сервера.
Дальше edge рантайм это обработает: проверит реврайты и редиректы -> проведёт через middleware -> посмотрит есть ли в кеше -> если сегмент в edge рантайме - выполнит его у себя, если нет - отправит запрос на оригинальный сервер (но про все эти порядки в Edge рантайме и внутренности Vercel нигде не пишет, но как вижу это именно так).
Если npm start запускает именно сервер, что (и как) запускает edge рантаймы?
Vercel после сборки просто отправляет новый код edge рантайма (они недавно, кстати, сделали его компиляцию в машинный код) на сервера и те просто начинают работать с этим кодом.
Так и не понял, в каком случае вот прям нужно перекладывать работу на Edge
Ну по этой части я писал - хорошо использовать когда можно сделать всю обработку внутри (Запрос будет Client -> Edge). Если же нужно ходить к основному серверу (допустим на БД которая подключена внутри проекта, или файлы читать по какой-то причине) - это будет не выгодно. То есть запрос всё равно будет Client -> Edge -> Server. А раз всё равно ходите на сервер - лучше сразу всю обработку сделать в нём - в нём есть весь кеш, БД лежит рядом, система рядом, да и в целом возможностей больше.
Именно. Это пререндер статики. Чтобы пользователь и роботы при обращении получили сразу готовый html. А уже после этого на клиенте загрузиться вся логика, пройдёт гидрация и соберётся реативное приложение.
Ну а edge может дать прирост во времени ответа сервера (и, как следствие, метрики FCP) - что будем ждать эту статику не 500мс, а 300мс. Учитывая что задержка сейчас часто дольше чем сама загрузка - в некоторых случаях может дать неплохой буст (но, конечно, много переменных).
Да, но как. Они рендерят статическую часть при сборке и оставляют слоты/ссылки на динамические компоненты. Или всё же пересобирают и статическую часть по запросу, но каким-то супер оптимизированным способом и то, что динамическое собирают полноценно. А общение между этими частями как, допустим если со статической части передать пропсом объект с ценами.
Поэтому ждём. Из-за этого например и авторы библиотек переводов аккуратно подходят к реализациям получения локали (переписывался в дискуссиях с автором next-intl в меру общей проблемы).
Мне по большей части нравится новое кэширование и фокус на нём. Да, оно не лишено недостатков, но так как это одна из ключевых фичей нового App Router, думаю в будущем нас ждут только улучшения.
Ух, next v15 вас удивит, но практически все кеширования будут отключены по умолчанию. Лично я этому рад, потому что мы кешировали достаточно много информации, а реализации next-а оказалась хуже нашей, но при этом мешала и просто работала поверх (ещё и сборка в несколько процессов портила идеальное кеширование нашей реализацией, посмотрим как они это обойдут в новой версии). Кеширование ломает гибкость и специфики, поэтому это должно быть решением команд (хотя бы обычный флаг).
Они как я понимаю откажутся от сильного кеширования и скажут, что PPR решит все ваши проблемы.
Проблема серверных компонентов на мой взгляд только в том, что у них сильно отличается ментальная модель от того, к чему привыкло большинство разработчиков
Я бы главным назвал необходимость использовать prop drilling. Когда у тебя десятки уровней вложенности - это ужас (а то как извращаются библиотеки переводов чтоб найти решения - ух... [но я и сам в обходе немного так наделал]).
сломана вставка CSS стилей ... Они починили это только в 14.2.
Я в 14.3.1 поймал... Когда компонент рендерится только на клиенте. Ну а в первых версиях вообще часто ломалось, да.
Да, есть cache из Реакт, но это работает только как аналог Memoization из Next.js. Есть аналог для Data Cache в виде функции unstable_cache
cache реакта отлично себя показывает. unstable_cache лучше тем, что он кеширует поверх процессов, ещё и сохраняет инфу между пересборками (как и fetch, это в целом под капотом одна функция, которую можно реализовать по-своему - cacheHandler)
И вот здесь publishAction станет API роутом, а в form передастся url этого API. Соответственно при отправке формы не нужно будет ждать пока загрузится её логика
А что в изменениях next.js нравится и упростило написание кода (именно next.js, т.е. навигация в app router, новые роуты и абстракции, кеширование и т.п.)?
Всё ещё испытываю очень спорные эмоции и хочу понять в чём улучшило жизнь другим (или ухудшило, тоже очень интересно, особенно если решу писать по нему ещё статьи).
Можно сказать, что nextjs исполняется в четырёх средах: сервер, клиент, edge и сборка. Сам он для конфигурации предлагает использовать env файлы и два вида переменок - серверные и публичные (начинаются с NEXT_PUBLIC_ и будут встроены в код во время сборки).
Для edge рантайма и клиента приходится использовать публичные переменные. А это в свою очередь означает, что приложение будет полностью зафиксировано под окружение в момент сборки.
Пакет же даёт возможность настроить файлы конфигураций в стиле, схожем с пакетом config, под каждую среду и использовать их в нужных местах в нужном окружении.
Layout просто совсем непрактичная штука и подходит для очень ограниченного списка проектов.
Мои взгляды, что на layout нужно забивать и, если там используются контексты/получение пути/разных данных страницы - кидать ошибку. Применение контекстов можно посмотреть в библиотеке next-translation, где я рекомендую инициализировать провайдер на каждой странице.
Тоже плохо с неймингом у команды реакта получилось, что серверные компоненты назвали серверными. Безумное количество раз слышал странные выводы исходя из этого деления (серверные/клиентские). По факту это скорее static components/assembler components.
Профдеформация видимо... Слишком часто натыкаюсь на статьи формата "React VS Next, что лучше". Часто не понимают почему такое сравнение бред (уровня git VS github) и зачем вообще все эти нагромождения, вот и перестал воспринимать это по-умолчанию как сарказм и шутки 😬
Спасибо за комментарий! Добавил эти моменты также в саму статью
Тут вопросы про CDN в целом. Не стал особо затрагивать тему, так как хотел базовую статью про отличительные особенности именно для фронтендеров.
Сам Vercel использует edge рантайм вообще для всех приложений и всех запросов. То есть вы подключили домен и Vercel сразу сказал, что этот домен лежит ещё и на этих вот точках по миру. В следующий раз, когда пользователь зайдёт на страницу - провайдер пойдёт спрашивать, а где этот домен лежит, ему в ответе прилетят доступные места и он выберет ближайшую и пойдёт на неё.
На этих точках всегда лежит логика кеширования, также, если в проекте есть реврайты, редиректы, middleware или сегменты в edge рантайме - после сборки он отправит это всё на edge сервера.
Дальше edge рантайм это обработает: проверит реврайты и редиректы -> проведёт через middleware -> посмотрит есть ли в кеше -> если сегмент в edge рантайме - выполнит его у себя, если нет - отправит запрос на оригинальный сервер (но про все эти порядки в Edge рантайме и внутренности Vercel нигде не пишет, но как вижу это именно так).
Vercel после сборки просто отправляет новый код edge рантайма (они недавно, кстати, сделали его компиляцию в машинный код) на сервера и те просто начинают работать с этим кодом.
Ну по этой части я писал - хорошо использовать когда можно сделать всю обработку внутри (Запрос будет Client -> Edge). Если же нужно ходить к основному серверу (допустим на БД которая подключена внутри проекта, или файлы читать по какой-то причине) - это будет не выгодно. То есть запрос всё равно будет Client -> Edge -> Server. А раз всё равно ходите на сервер - лучше сразу всю обработку сделать в нём - в нём есть весь кеш, БД лежит рядом, система рядом, да и в целом возможностей больше.
Надеюсь ответил на вопросы!
Именно. Это пререндер статики. Чтобы пользователь и роботы при обращении получили сразу готовый html. А уже после этого на клиенте загрузиться вся логика, пройдёт гидрация и соберётся реативное приложение.
Ну а edge может дать прирост во времени ответа сервера (и, как следствие, метрики FCP) - что будем ждать эту статику не 500мс, а 300мс. Учитывая что задержка сейчас часто дольше чем сама загрузка - в некоторых случаях может дать неплохой буст (но, конечно, много переменных).
Новость не заставила себя долго ждать ?
https://nextjs.org/blog/next-15-rc
Да, но как. Они рендерят статическую часть при сборке и оставляют слоты/ссылки на динамические компоненты. Или всё же пересобирают и статическую часть по запросу, но каким-то супер оптимизированным способом и то, что динамическое собирают полноценно. А общение между этими частями как, допустим если со статической части передать пропсом объект с ценами.
Поэтому ждём. Из-за этого например и авторы библиотек переводов аккуратно подходят к реализациям получения локали (переписывался в дискуссиях с автором next-intl в меру общей проблемы).
Надеюсь завтра на Vercel conf коснутся и некста, и PPR в целом как то, что сделает веб ещё быстрее и прочий маркетинг
Твиты разразоботчиков, PR-ы, подогревают тему скорых крупных изменений, ну и в целом время уже к релизу (4-ю минорку они делать не любят).
Честно признаюсь - не знаю. По видео пока вообще непонятно, как это технически будет работать (а по коду пока только мимопроходил)
Спасибо за подробный ответ!
Ух, next v15 вас удивит, но практически все кеширования будут отключены по умолчанию. Лично я этому рад, потому что мы кешировали достаточно много информации, а реализации next-а оказалась хуже нашей, но при этом мешала и просто работала поверх (ещё и сборка в несколько процессов портила идеальное кеширование нашей реализацией, посмотрим как они это обойдут в новой версии). Кеширование ломает гибкость и специфики, поэтому это должно быть решением команд (хотя бы обычный флаг).
Они как я понимаю откажутся от сильного кеширования и скажут, что PPR решит все ваши проблемы.
Я бы главным назвал необходимость использовать prop drilling. Когда у тебя десятки уровней вложенности - это ужас (а то как извращаются библиотеки переводов чтоб найти решения - ух... [но я и сам в обходе немного так наделал]).
Я в 14.3.1 поймал... Когда компонент рендерится только на клиенте. Ну а в первых версиях вообще часто ломалось, да.
cache реакта отлично себя показывает. unstable_cache лучше тем, что он кеширует поверх процессов, ещё и сохраняет инфу между пересборками (как и fetch, это в целом под капотом одна функция, которую можно реализовать по-своему - cacheHandler)
Server action (решал здесь, кстати, стоит переводить или нет). Честно говоря под катом этого не разбирался, но в целом это про:
const publishAction = (data) => {
"use server"
// ...
}
// ...
<form action={publishAction}>
// ...
И вот здесь
publishActionстанет API роутом, а в form передастся url этого API. Соответственно при отправке формы не нужно будет ждать пока загрузится её логикаПо второму дню статьи уже не будет, поэтому просто оставлю это здесь (для тебя, мой дорогой редкий читатель! ?)
Часть Windows построена на React Native!
После настройки:
const config = useRuntimeConfig();Есть вполне достаточный пример - https://github.com/vordgi/nimpl-config/blob/main/example. Ну и дока, конечно, тоже есть - https://nimpl.tech/config/usage)
А что в изменениях next.js нравится и упростило написание кода (именно next.js, т.е. навигация в app router, новые роуты и абстракции, кеширование и т.п.)?
Всё ещё испытываю очень спорные эмоции и хочу понять в чём улучшило жизнь другим (или ухудшило, тоже очень интересно, особенно если решу писать по нему ещё статьи).
(О своих итогах писал в первую очередь в статье про App Router и статье про кеширование в next.js)
Можно сказать, что nextjs исполняется в четырёх средах: сервер, клиент, edge и сборка. Сам он для конфигурации предлагает использовать env файлы и два вида переменок - серверные и публичные (начинаются с NEXT_PUBLIC_ и будут встроены в код во время сборки).
Для edge рантайма и клиента приходится использовать публичные переменные. А это в свою очередь означает, что приложение будет полностью зафиксировано под окружение в момент сборки.
Пакет же даёт возможность настроить файлы конфигураций в стиле, схожем с пакетом config, под каждую среду и использовать их в нужных местах в нужном окружении.
В общем интересный эксперимент как можно иначе конфигурировать fullstack приложение.
(Думаю [когда-нибудь, [надеюсь [и мне хочется верить]]], что я допишу по нему статью)
По идее, именно в плане настройки, между pages и app роутерами отличий в настройке кеширования нет (https://nextjs.org/docs/pages/building-your-application/deploying#configuring-caching). То есть пакет должен работать и с pages router.
Единственное, что в версиях до 13 эта настройка была под другими ключами, в experimental
Наконец дошли руки доделать пример с таким провайдером
https://github.com/vordgi/next-impl-getters/tree/main/examples/isomorphic-context
Layout просто совсем непрактичная штука и подходит для очень ограниченного списка проектов.
Мои взгляды, что на layout нужно забивать и, если там используются контексты/получение пути/разных данных страницы - кидать ошибку. Применение контекстов можно посмотреть в библиотеке next-translation, где я рекомендую инициализировать провайдер на каждой странице.
А вообще Next.js собирает страницу сверху вниз, он проходит сегмент за сегментом собирая абстракции на текущем уровне, но слои собираются отдельно от страниц. Там страшная логика, но основное лежит здесь: https://github.com/vercel/next.js/blob/79b7cb5f075c26698bc2cb8a569cda8a6e3b49bd/packages/next/src/server/app-render/create-component-tree.tsx#L433
Там вероятно есть клиентское кеширование темплейта. Спасибо за случай, обдумаю.
А работать такое [как я написал выше] должно, попробую на днях добавить пример.
Тоже плохо с неймингом у команды реакта получилось, что серверные компоненты назвали серверными. Безумное количество раз слышал странные выводы исходя из этого деления (серверные/клиентские). По факту это скорее static components/assembler components.
Ну с переводами сложно, да. Для них я по итогу сделал своё решение и об этом следующая статья)
Больше библиотек богу библиотек или как я переосмыслил i18n [next.js v14]