Комментарии 10
а сделав мини-приложения, способные даже рендерить страницы в ближайшей к пользователю точке.
Следующий этап - рендерить страницы непосредственно в устройстве пользователя.
Это и так делается благодаря природе React) речь о изначальной версии страницы, чтобы юзер начал видеть контент вместо ожидания на белом экране
Именно. Это пререндер статики. Чтобы пользователь и роботы при обращении получили сразу готовый html. А уже после этого на клиенте загрузиться вся логика, пройдёт гидрация и соберётся реативное приложение.
Ну а edge может дать прирост во времени ответа сервера (и, как следствие, метрики FCP) - что будем ждать эту статику не 500мс, а 300мс. Учитывая что задержка сейчас часто дольше чем сама загрузка - в некоторых случаях может дать неплохой буст (но, конечно, много переменных).
Кажется, никто не выкупил шутку :(
Как же сложно... Так и не понял, в каком случае вот прям нужно перекладывать работу на Edge, и как именно оно будет работать. Если npm start запускает именно сервер, что (и как) запускает edge рантаймы? Как они взаимодействуют с основным сервером? Версель как-то детектит, что в проекте есть использование edge рантаймов и начинает перенаправлять запросы туда вместо прямых запросов на сервер? Все запросы или не все? А сколько под проект выделить точек в своей network (и где) версель сам решает по метрикам проекта? Или я вообще не так понял это всё?
Как они взаимодействуют с основным сервером? Версель как-то детектит, что в проекте есть использование 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. А раз всё равно ходите на сервер - лучше сразу всю обработку сделать в нём - в нём есть весь кеш, БД лежит рядом, система рядом, да и в целом возможностей больше.
Надеюсь ответил на вопросы!
Публикации
Vercel VS Edge VS Next. Что такое Vercel Edge, зачем, как и куда