Edge против Node в проде: изоляты, холодные старты и ловушка локальности данных

V8-изоляты: чего на самом деле стоит почти нулевой холодный старт

Edge runtime — это не «Node поменьше», это другая модель исполнения. Ваш код работает в V8-изоляте: свежем JavaScript-контексте, порождаемом внутри уже работающего процесса, — архитектура, которую первым сделал Cloudflare Workers. Породить изолят — значит выделить кучу и глобальный объект: единицы миллисекунд, часто меньше. Холодный старт Node-лямбды — это, напротив, стопка настоящей работы: поднять microVM (~50–200 мс), загрузить сам Node (~50–100 мс), затем require фреймворка и графа страницы (50–500 мс, на тяжёлых деревьях зависимостей — секунды). Вот честный диапазон за фразой «у edge ~0 холодных стартов против 200–800 мс»: изоляты пропускают загрузку, а не физику. Тёплые вызовы на обоих рантаймах различаются единицами миллисекунд — весь latency-аргумент за edge — это холодный путь и география.

Цена — поверхность API. Изолят даёт только Web API — fetch, Request/Response, URL, crypto.subtle, стримы — и ничего из Node: ни fs, ни net, ни child_process, ни нативных аддонов. Последнее кусает больнее всего: sharp, bcrypt, всё с бинарником .node и классические драйверы БД с нативными движками — мимо; нужны WASM-сборки, HTTP-драйверы для serverless или другой рантайм. Динамическое исполнение кода (eval, new Function) запрещено наотрез. Бандлы ограничены — порядка 1–4 МБ в сжатом виде в зависимости от плана, — потому что модель изолятов остаётся дешёвой, только пока код маленький. Next позволяет выбирать рантайм на сегмент роутинга — в этом и смысл: решение не общеприложенческое.

// app/api/checkout/route.ts — рядом с базой: остаёмся на Node
export const runtime = 'nodejs';

// app/api/geo-banner/route.ts — без данных, чувствителен к latency: edge — бесплатная скорость
export const runtime = 'edge';

export async function GET(request: Request) {
  const country = request.headers.get('x-vercel-ip-country') ?? 'US';
  return Response.json({ banner: country === 'DE' ? 'eu-promo' : 'default' });
}

Ловушка локальности данных

Числа, решающие спор edge против node, — это RTT (Round-Trip Time, время прохождения пакета туда и обратно), и их асимметрия безжалостна: внутри региона меньше 1–2 мс, через США 60–80 мс, через Атлантику 80–100 мс, США–APAC 180–250 мс. Latency роута — примерно RTT клиент→compute + N последовательных запросов × RTT compute→данные + работа. Node рядом с базой делает длинный хоп один раз — клиентский RTT, — а каждый запрос после этого субмиллисекундный. Edge переворачивает: первый хоп сжимается до единиц миллисекунд, но каждый последовательный запрос теперь платит полный RTT compute→данные. Один запрос — примерно ничья. Четыре последовательных запроса из сиднейского PoP в вирджинский Postgres — это 800+ мс одного только RTT, строго хуже того, что было, — ровно инцидент из вступления. Есть и вторая, тихая статья расходов: классические пулы TCP-соединений с базой не выживают в модели изолятов, поэтому доступ к БД с эджа идёт через HTTP-драйверы — каждый запрос несёт HTTP-накладные вместо тёплого сокета из пула.

Значит, edge-compute выигрывает ровно в двух ситуациях. Вычисления, не трогающие данные: редиректы, геоперсонализация по заголовкам запроса, раскладка по A/B-корзинам, проверка подписанного токена через crypto.subtle — чистый CPU над самим запросом, и выполнять его в 10 мс от пользователя вместо 200 — бесплатная скорость. Либо данные, реплицированные туда, где работает compute: edge-KV, кеши в PoP (Point of Presence — точка присутствия сети), региональные read-реплики — чтения локальны, и география работает на вас. Оба условия вместе задают одну чёткую границу: если роут не свободен от данных и данные не реплицированы в PoP, edge сделает его медленнее, а не быстрее. Всё остальное — чекаут, дашборд с N запросами, любая транзакционность против одного регионального primary — живёт на Node в регионе базы, где последовательные запросы стоят микросекунды, а длинный хоп пользователь платит ровно один раз.

Middleware — налог на каждый запрос

Middleware в Next выполняется до кеша и роутера, на каждом запросе, пропущенном matcher-ом: страницы, RSC-payload, префетчи, а при неряшливом matcher — и статика. Это делает его latency плоским налогом на весь сайт: всё, что делает middleware, прибавляется к каждому TTFB (Time To First Byte — время до первого байта ответа). Дисциплина, держащая налог около нуля: middleware занимается решениями о маршрутизации, перезаписью заголовков и cookie и локальной проверкой подписанных токенов — HMAC или проверка подписи JWT через crypto.subtle стоит десятки микросекунд и ничего не трогает. Чего он не должен делать никогда — разговаривать с базой или делать fetch в собственный API: middleware, дёргающий /api/session, чтобы закрывать роуты, ставит круговой хоп edge→origin плюс запрос в БД перед каждой загрузкой каждой страницы, удваивая TTFB глобально, — и это невидимо в профилировании по роутам, потому что цена ложится до старта роута.

// middleware.ts — проверяй локально, никогда не fetch-ай собственный API отсюда
import { NextResponse } from 'next/server';
import { jwtVerify } from 'jose';

export const config = {
  matcher: ['/((?!_next/static|_next/image|favicon.ico).*)'], // исключи ассеты — иначе платят и они
};

export async function middleware(req: Request) {
  const token = req.headers.get('cookie')?.match(/__Host-session=([^;]+)/)?.[1];
  if (!token) return NextResponse.redirect(new URL('/login', req.url));
  try {
    await jwtVerify(token, secret); // локальная криптография: ~0,05 мс, ноль IO
    return NextResponse.next();
  } catch {
    return NextResponse.redirect(new URL('/login', req.url));
  }
}