Next.js

Для чего модуль

Научиться проектировать Next.js-приложение как production-систему: с понятными границами server/client, предсказуемым кэшем и управляемой стоимостью рендера.

Результат после прохождения

1. Вы осознанно выбираете SSR/SSG/ISR/dynamic rendering под конкретный экран.
2. Вы управляете revalidate, tag/path invalidation и не получаете «случайно устаревший UI».
3. Вы проектируете границы между Server/Client Components без лишнего JS в браузере.
4. Вы умеете диагностировать hydration и data-fetching проблемы через воспроизводимый runbook.

Термины и аббревиатуры

Термин	Коротко
App Router	Маршрутизация Next.js
ISR	Инкрементальное обновление
Streaming	Частичная отправка HTML
Revalidation	Обновление кэша
TTFB	Время до первого байта

Фокус по грейдам

1. Junior: понимать базовые механики и объяснять их простыми примерами.
2. Middle: применять тему в продуктовых сценариях с учетом рисков и ограничений.
3. Senior: управлять архитектурными trade-offs, метриками и эволюцией решения.

Как работать с модулем

1. Берите один реальный экран и прогоняйте его через все уроки.
2. Каждый архитектурный выбор фиксируйте через trade-off: UX, SEO, latency, стоимость сопровождения.
3. Для каждой гипотезы делайте замер до/после, а не «ощущение, что стало лучше».

Программа модуля

Урок 1. App Router и архитектура

Цель: строить структуру Next-приложения так, чтобы она масштабировалась без хаоса.

Ментальная модель App Router

1. layout.tsx задает каркас и может переиспользоваться между маршрутами.
2. page.tsx отвечает за конкретный route-level UI.
3. route.ts (Route Handlers) — backend-граница внутри Next.
4. Server Components — default; Client Components — только где нужен браузерный runtime.

Server vs Client boundaries

Простой критерий:

1. Нужен доступ к browser API/hooks событий? Это use client.
2. Нужны секреты/бэкенд-запросы/уменьшение JS bundle? Оставляйте server-side.

// app/users/page.tsx (Server Component)
import UsersList from './UsersList';

export default async function UsersPage() {
  const users = await fetchUsers();
  return <UsersList initialUsers={users} />;
}

// app/users/UsersList.tsx
'use client';

Где ломается в проде

1. use client ставится слишком высоко по дереву и тянет лишний JS.
2. Бизнес-логика размазывается между route и component слоями.
3. Непрозрачные импорты: server module попадает в client bundle.

Мини-задача (обязательная)

Разбейте один сложный экран на Server/Client Components. Для каждой границы дайте аргумент: что выигрываем и какой риск получаем.

Что спросит интервьюер: когда use client обязателен, а когда это лишний JS в браузере.

Критерий готовности по уроку: вы можете объяснить структуру App Router модуля так, чтобы новый разработчик без боли продолжил работу.

Урок 2. Рендер и кэш

Цель: выбирать стратегию рендера и кэша через требования, а не привычку.

Карта рендер-стратегий

1. SSG — контент почти статичен, важны скорость и SEO.
2. ISR — контент меняется периодически, нужен баланс свежести и цены.
3. SSR/dynamic — данные зависят от пользователя/контекста запроса.
4. CSR — интерактивные зоны, где серверный рендер не дает выгоды.

Revalidation и инвалидация

await fetch('https://api.example.com/products', {
  next: { revalidate: 300, tags: ['products'] },
});

// после мутации
revalidateTag('products');

Ключевая мысль: кэш без стратегии инвалидции почти всегда превращается в баг с устаревшими данными.

Freshness vs latency vs cost

1. Максимальная свежесть = больше server work и выше cost.
2. Агрессивный кэш = быстрее, но выше риск stale UI.
3. Правильный баланс зависит от бизнес-критичности данных.

Где ломается в проде

1. Один и тот же endpoint рендерится в разных режимах без единой политики.
2. Нет понятных правил, какие данные «могут стареть», а какие нет.
3. После мутаций забывают инвалидировать нужные path/tag.

Мини-задача (обязательная)

Для 4 страниц (лендинг, каталог, карточка товара, личный кабинет) выберите рендер-режим и cache policy с аргументацией.

Что спросит интервьюер: почему выбран SSR/SSG/ISR и как вы это проверили метриками.

Критерий готовности по уроку: вы можете защитить стратегию рендера через бизнес-требования и замеры.

Урок 3. Data fetching и UX

Цель: сделать UX устойчивым к задержкам, ошибкам и частично доступным данным.

Loading/Error/Empty как контракт

На каждом data route должны быть продуманы состояния:

1. loading.tsx — что пользователь видит во время ожидания.
2. error.tsx — как восстанавливаться после сбоя.
3. empty-state — как объяснить отсутствие данных.

Streaming и progressive rendering

Streaming полезен, когда часть экрана можно показать раньше, не дожидаясь медленного блока данных.

Hydration mismatch: причины и профилактика

1. Нестабильные значения на сервере и клиенте (Date.now, random).
2. Разная логика форматирования/локали.
3. Побочные эффекты в render-phase.

// Плохо: нестабильное значение прямо в рендере
<p>{Date.now()}</p>

Где ломается в проде

1. При ошибке API экран «молча пустой» вместо контролируемого fallback.
2. Loading-компонент не отражает реальную структуру экрана -> скачки layout.
3. Ошибка в Route Handler маскируется generic 500 без trace context.

Мини-задача (обязательная)

Реализуйте страницу с loading.tsx, error.tsx и пустым состоянием. Добавьте один кейс hydration mismatch и зафиксируйте, как вы его устранили.

Что спросит интервьюер: как вы предотвращаете hydration mismatch в сложных экранах.

Критерий готовности по уроку: вы можете показать стабильный UX при медленной сети и объяснить, почему он устойчив.

Урок 4. Reliability и delivery

Цель: довести Next-приложение до эксплуатационного уровня.

Auth и security boundary

1. Не держите чувствительную логику в client-only слое без причины.
2. Четко разделяйте публичные и защищенные маршруты.
3. Для критичных операций добавляйте audit trail и trace correlation.

Perf budgets и контроль деградации

1. Для ключевых маршрутов задайте budgets по TTFB/LCP/INP.
2. Любая оптимизация проходит через baseline и повторный замер.
3. Релиз блокируется при нарушении критичных budget порогов.

Observability и rollback

1. Логи фронта и route handlers должны коррелироваться по trace/request id.
2. Есть playbook: что делаем при росте ошибок/latency.
3. Rollback — это заранее подготовленная процедура, а не импровизация.

Мини-задача (обязательная)

Подготовьте Next release checklist: кэш, auth, CWV budgets, error-rate, rollout strategy, rollback conditions.

Что спросит интервьюер: какие риски вы видите при росте проекта и как их закроете.

Критерий готовности по уроку: вы можете описать эксплуатационный контур Next-приложения и доказать, что он снижает риск инцидентов.

Практика

Работайте через 4 проверяемых блока. Каждый блок должен закончиться артефактом, который можно показать на interview review.

Блок	Ответить	Practice action	Readiness
App Router and boundaries	Next.js q-1..q-3, q-11..q-12	Free-practice: Server/Client boundary map для сложного экрана: route segments, layout, page, Route Handler, client islands, forbidden imports	Вы объясняете, где нужен use client, где остаются server-only данные, и какой bundle/security риск дает каждая граница
Rendering and cache policy	Next.js q-4..q-5, q-18, Senior q-3	Render/cache decision table для 6 экранов: SSG, ISR, SSR/dynamic, CSR island, revalidate, tag/path invalidation, freshness SLA	Вы выбираете стратегию через freshness -> latency -> cost -> user risk, а не через привычку
Data fetching and UX states	Next.js q-6..q-10, q-14	Free-practice: page state runbook with loading.tsx, error.tsx, empty-state, hydration mismatch reproduction and fix	Вы показываете стабильный UX при медленной сети, controlled fallback и причину hydration mismatch до фикса
Runtime, auth and release reliability	Next.js q-13, q-15..q-20, Senior q-12	Next release checklist: auth boundary, runtime choice, env exposure, cache invalidation test, CWV budgets, observability, rollout, rollback	Вы называете block/review/accept risks и можете объяснить, как остановить релиз при stale UI, auth leak или perf regression

Если блок получает partial или not ready, не переходите к следующему модулю: повторите связанные вопросы и перепишите артефакт до состояния context -> decision -> risk -> metric -> verification.

Связь с треками и вопросами

1. Треки: Middle трек, Senior трек.
2. Вопросы: Next.js q-1..q-20, Senior q-3, Senior q-12, Senior q-14.
3. Route practice: Middle день 5, Middle день 9, Senior день 4, Мосты практики: HTML, CSS and rendering, React rendering and effects, Testing frontend.
4. Повторение через 24 часа: один вопрос про App Router boundary, один про cache invalidation, один про loading/error states, один про runtime/release risk.

Критерий готовности

Ready, если вы защищаете Next-архитектуру как инженерное решение:

1. context -> choice -> risk -> metric -> operation plan;
2. для каждого route есть render/cache policy и причина, почему данные могут или не могут стареть;
3. Server/Client boundary уменьшает client JS и не уносит secret/server-only логику в браузер;
4. loading/error/empty/hydration сценарии воспроизводимы и имеют понятную проверку;
5. release checklist содержит cache, auth, runtime, CWV budgets, observability, rollout и rollback.

Partial, если вы знаете термины, но не можете показать artifact, metric или invalidation test. Not ready, если ответ сводится к "SSR для SEO", "ISR для скорости" или "revalidate после мутации" без freshness risk и verification.

Артефакты после модуля

1. Таблица рендер-стратегий по маршрутам продукта.
2. Server/Client boundary map.
3. Cache policy документ с правилами инвалидации.
4. Runbook по hydration/data-fetching инцидентам.
5. Next release checklist.
6. Набор из 8 сильных interview-ответов по Next.js.

Куда дальше

1. Frontend-архитектура
2. Frontend System Design
3. Next.js