Senior internals: RSC payload, слои кэша и production падения

Формат RSC Payload по wire

После этого урока ты сможешь объяснить формат RSC Payload, восстановить цепочку многослойного кэш-бага и обнаружить hydration-несоответствие до того, как его зарепортит пользователь.

Когда React рендерит дерево Server Component’ов, вывод — не HTML и не JSON. Это RSC Payload — кастомный стримящийся формат разработанный для инкрементальной обработки по мере прихода по сети.

Формат использует row-prefix коды:

• M — module reference (URL bundle клиентского компонента)
• J — JSON literal (сериализованные props или данные)
• H — hint (директива браузера типа prefetch)

Каждая строка ссылается на предыдущие строки по ID, инкрементально строя React-дерево. Пример:

0:["$","div",null,{"children":[["$","h1",null,{"children":"Товар"}]]}]
1:{"id":42,"name":"Товар","price":29.99}

React клиент браузера обрабатывает эти строки по мере их прихода, включая то же “стримить HTML, рендерить что есть” поведение описанное в уроке про Suspense — но для обновлений React-дерева, не только начального HTML.

RSC Payload — механизм за Next.js client-side навигацией: вместо загрузки новой HTML страницы, клиент fetch’ит RSC Payload для нового роута и применяет к существующему React-дереву. Это делает навигации мгновенными потому что шелл (лэйаут, nav) никогда не перерисовывается.

Server Functions: типобезопасный RPC через HTTP

React 19 вводит Server Functions — async функции помеченные 'use server' которые могут вызываться из Client Components, но выполняются на сервере. Фреймворк генерирует стабильный POST endpoint для каждой; client-side вызов становится типизированным fetch.

// actions.ts
'use server';
export async function likePost(postId: string) {
  await db.post.update({ where: { id: postId }, data: { likes: { increment: 1 } } });
  revalidatePath('/posts');
}

// PostCard.tsx — Client Component
'use client';
import { likePost } from './actions';
export function PostCard({ postId }) {
  return <button onClick={() => likePost(postId)}>Лайк</button>;
}

TypeScript видит likePost как обычную типизированную функцию. Не нужно определять REST роут, типы request/response или форму обработки ошибок. Аргументы сериализуются автоматически; тело функции никогда не попадает в клиент.

В сочетании с form actions (<form action={serverFunc}>), Server Functions включают progressive enhancement: форма работает без JavaScript потому что браузер сабмитит на сгенерированный endpoint напрямую.

Ограничения: аргументы должны быть сериализуемы (нет class instances, нет функций). Аутентификация должна быть явной внутри функции. Никогда не доверять client-предоставленным ID для проверок владения без повторной валидации на сервере.

Слои кэша и координированная инвалидация

Современное Next.js 15 приложение имеет минимум пять слоёв кэширования:

1. CDN edge кэш — по URL, секунды до часов. Обслуживает статический контент без обращения к origin.
2. Next.js fetch кэш — вызовы RSC fetch() кэшируются по умолчанию с настраиваемым revalidate периодом.
3. Database query кэш — Redis или in-memory, перед базой данных.
4. Браузерный HTTP кэш — контролируется Cache-Control заголовками.
5. Client library кэш — TanStack Query / SWR, по queryKey.

Пять слоёв — пять точек отказа. Мутация, которая инвалидирует слои 1–4 но пропускает слой 5, оставляет пользователя смотреть на устаревшие данные до gcTime (по умолчанию 5 минут) — без ошибок, без предупреждений, просто неверные цифры на экране.

Мутация изменяющая данные должна инвалидировать нужные слои:

// На сервере (Server Function или route handler)
revalidatePath('/products');      // Next.js кэш + CDN если настроен
revalidateTag('product-42');      // гранулярная tag-based CDN очистка

// На клиенте
queryClient.invalidateQueries({ queryKey: ['product', 42] });

Пропуск любого слоя оставляет пользователей смотреть на устаревшие данные. Самый распространённый баг: серверный кэш инвалидирован, но клиентский TanStack Query кэш продолжает отдавать старый ответ следующие 5 минут.

Hydration несоответствия: тихие баги интерактивности

React’s hydration предполагает что server-rendered DOM точно совпадает с тем что клиент бы отрендерил с теми же props. Когда они расходятся, reconciler React’а пытается исправить DOM, но его модель того, какие event handlers принадлежат каким DOM узлам, теперь несогласована — клики могут срабатывать на неправильном handler’е или тихо теряться.

Распространённые причины:

• Date.now() или Math.random() рендерятся с обеих сторон — разные значения
• Условный рендеринг на основе window.innerWidth — сервер не имеет window
• Чтение localStorage на уровне модуля

Видимый вывод выглядит корректно, потому что и сервер и клиент рендерят валидный HTML. Но биндинги event handler’ов не согласованы.

Паттерны фикса:

• useEffect для client-only логики: рендерить безопасное начальное состояние с обеих сторон; изменять на client-specific состояние после завершения hydration
• suppressHydrationWarning: валидно для genuinely расходящихся листьев (timestamps с locale)
• Client Components для контента который фундаментально client-specific

Когда видишь кнопку, которая иногда игнорирует клик — не выбрасывает ошибку, просто ничего не делает, — подозревай hydration-несоответствие раньше, чем начнёшь читать логику event handler’а.

React 19 улучшил сообщения об ошибках hydration для локализации несовпадающего элемента; до React 19 сообщение было generic. Production команды инструментируют hydration ошибки через error boundaries отправляющие в Sentry — стабильный ненулевой rate сигнализирует о накапливающихся несоответствиях до того как они всплывут как user-reported баги.

Edge runtime для data fetching

Edge runtime (Next.js Edge, Cloudflare Workers, Vercel Edge) запускает серверный код на CDN узлах вместо центрального дата-центра. Задержка до пользователя: единицы ms vs сотни для традиционных серверов.

Лучшее применение: глобально-реплицированные источники данных (Cloudflare D1, Turso, PlanetScale) где edge сервер fetch’ит из ближнего реплики. Edge-rendered RSC даёт первый paint за 50–100ms независимо от географии.

Ограничения: ограниченные API (нет Node.js fs, нет нативных модулей), только Web-стандартные API (fetch, crypto.subtle), меньшие лимиты памяти на запрос.

Реальные production падения

Vercel 2024 — server-side waterfall: RSC миграция клиента регрессировала TTFB со 100ms до 2.5s. Корневая причина: Server Component fetch’ил 50 товаров в последовательном цикле for...await вместо Promise.all. Обнаружено observability dashboards зафиксировавшими спайк p95 TTFB; исправлено оборачиванием в Promise.all. Урок: последовательный await в Server Components — server-side waterfall с той же ценой что и client-side — он блокирует Suspense boundary от стриминга.

Spotify Web Player 2023 — неполный optimistic snapshot: Optimistic update для “добавить в плейлист” использовал setQueryData, но onMutate не делал snapshot предыдущего состояния. Когда сервер отклонил запрос, откат установил значение кэша в undefined вместо реального предыдущего состояния — плейлисты визуально исчезали на несколько секунд. Исправлено каноническим паттерном: всегда вызывать queryClient.getQueryData в onMutate перед optimistic update’ом.

Linear 2024 — потеря сообщений при SSE переподключении: Server-Sent Events based real-time синхронизация использовала client-generated схему message ID. При переподключении клиент пропускал сообщения отправленные во время окна отключения — пользователи видели как карточки “отпрыгивают” после drag операций. Исправлено server-assigned монотонными ID и протоколом возобновления на основе Last-Event-ID который сервер использует для повтора пропущенных сообщений.