Коротка відповідь. Next.js – це фреймворк поверх React, який відповідає за те, чого в самому React немає: роутинг, рендеринг на сервері, збірку й оптимізації. Перед співбесідою достатньо впевнено розуміти чотири речі: навіщо він потрібен, чим відрізняються стратегії рендерингу (SSR/SSG/ISR + Server Components), як влаштований роутинг в App Router і як там працює data fetching. Зубрити конфігурації напам'ять не треба – треба вміти пояснити, коли і що обирати.

React – бібліотека для UI: компоненти, стан, рендеринг. Усе інше застосунку – маршрути, серверний рендеринг, розбиття бандла, оптимізація зображень і шрифтів, API-ендпоїнти – React свідомо не вирішує. Можна зібрати це самостійно з окремих інструментів, а можна взяти фреймворк, де це вже інтегровано й підтримується як єдине ціле.

Сама документація React рекомендує починати нові продакшн-застосунки з фреймворка. На співбесіді відповідь «Next.js дає роутинг, серверний рендеринг і збірку з коробки, тому команда не підтримує цю інфраструктуру сама» – коротка і достатня.

Стратегії рендерингу простими словами

Головна тема будь-якої співбесіди про Next.js. Суть кожної стратегії – коли і де генерується HTML:

Стратегія Коли генерується HTML Коли обирати
SSG (static) Один раз під час build Контент однаковий для всіх і змінюється з деплоєм: лендинги, блог, документація
ISR (incremental) Під час build + перегенерація за інтервал або за запитом Статика, яка оновлюється без редеплою: каталог товарів, новини
SSR (dynamic) На кожен запит на сервері Відповідь залежить від користувача чи моменту: кабінет, стрічка, пошук
CSR У браузері після завантаження JS Інтерактивні частини за логіном, де SEO неважливе: дашборди, редактори

Питання-пастка: «що краще – SSR чи SSG?». Правильна відповідь – контрзапитання: чи однаковий контент для всіх користувачів і як часто він змінюється. Стратегія обирається на рівні сторінки, а не застосунку: у одному проєкті лендинг може бути статичним, а кабінет – динамічним.

Server Components: у чому ідея

В App Router компоненти за замовчуванням серверні: вони виконуються тільки на сервері, їхній код не потрапляє в браузерний бандл, і вони можуть напряму читати дані (базу, файли, API). Клієнтськими стають лише компоненти з директивою 'use client' – ті, яким потрібні стан, ефекти чи обробники подій.

Практичний наслідок, який варто озвучити на співбесіді: інтерактивність опускається якнайнижче по дереву. Сторінка-список – серверна, а клієнтський у ній лише пошуковий інпут. Менше клієнтського JS – швидше завантаження.

Типове уточнення від інтерв'юера: Server Components – це не SSR у старому сенсі. SSR рендерить HTML, але весь код компонентів усе одно їде в браузер для гідратації. Серверні компоненти в браузер не потрапляють узагалі.

Роутинг і data fetching в App Router

Роутинг – файловий: структура папок в app/ і є маршрутами.

app/
  page.tsx            →  /
  blog/
    page.tsx          →  /blog
    [slug]/page.tsx   →  /blog/:slug   (динамічний сегмент)
  layout.tsx          →  спільна обгортка, не перемонтовується між сторінками

Данні в серверних компонентах отримують просто через async/await – без ефектів і клієнтських хуків:

// app/blog/[slug]/page.tsx – серверний компонент
export default async function ArticlePage({
  params,
}: {
  params: Promise<{ slug: string }>;
}) {
  const { slug } = await params;
  const article = await getArticle(slug); // прямий виклик на сервері
  return <Article data={article} />;
}

Для статичної генерації динамічних маршрутів є generateStaticParams – список slug-ів, які треба зрендерити під час build. Порівняй це з класичним клієнтським підходом «useEffect + fetch + стани завантаження» – і зможеш аргументовано пояснити різницю: менше водоспадів запитів, менше клієнтського коду, дані ближче до джерела.

Типові питання співбесід – з відповідями

– Чим SSG відрізняється від ISR? SSG генерує сторінку раз під час build; ISR – це той самий SSG, але сторінка може перегенеруватися після деплою: за таймером або за запитом. Обираю ISR, коли контент змінюється частіше, ніж хочеться деплоїти.

– Коли компонент має бути клієнтським? Коли йому потрібні стан, ефекти, браузерні API або обробники подій. Усе інше лишаю серверним, щоб не роздувати бандл.

– Де в Next.js жити API-логіці? Route handlers для публічних ендпоїнтів; для внутрішніх потреб сторінки часто достатньо прямого виклику з серверного компонента – окремий ендпоїнт не потрібен.

– Як Next.js впливає на продуктивність? Автоматичне розбиття коду по маршрутах, оптимізація зображень і шрифтів, серверні компоненти без клієнтського JS. Але фреймворк не скасовує профілювання React-частини – зайві ре-рендери лишаються твоєю відповідальністю.

Кешування й ревалідація: мінімум, який треба розуміти

Друга за частотою тема після стратегій рендерингу. Ідея проста: статично згенерована сторінка – це кеш, і в нього мають бути правила оновлення.

// Перегенерація сторінки не частіше ніж раз на годину (ISR)
export const revalidate = 3600;

// Або точково: перегенерувати після зміни даних
import { revalidatePath } from 'next/cache';
await revalidatePath('/blog');

На співбесіді достатньо пояснити різницю двох підходів: за часом (сторінка може бути застарілою до N секунд – прийнятно для каталогу) і за подією (оновили запис у CMS → зревалідували конкретний шлях – точніше, але потребує інтеграції). І назвати чесний компроміс: агресивне кешування = швидкість і дешевизна, слабке кешування = свіжість даних і більше навантаження.

Мінімальний план підготовки за три вечори

  1. Вечір 1 – рендеринг. Створи проєкт, зроби три сторінки: статичну, динамічну (SSR) і ISR з revalidate. Подивись у build-лог, як Next.js позначає кожну (static / dynamic). Поясни собі вголос, чому саме так.
  2. Вечір 2 – роутинг і дані. Динамічний маршрут [slug] + generateStaticParams + async-сторінка з реальним запитом. Додай loading.tsx і not-found.tsx – і зрозумій, коли кожен показується.
  3. Вечір 3 – межа клієнт/сервер. Візьми сторінку-список і додай до неї клієнтський пошук. Мета – усвідомити, чому 'use client' стоїть на маленькому інпуті, а не на всій сторінці, і що станеться з бандлом, якщо зробити навпаки.

Після цих трьох вправ ти зможеш відповідати з власного досвіду, а не з чужих конспектів – різницю інтерв'юер чує з першої відповіді.

Чого НЕ треба вчити напам'ять

  • Точні назви конфіг-опцій і сигнатури API – це документація, вона під рукою і в тебе, і в інтерв'юера.
  • Відмінності всіх історичних версій Pages Router – достатньо знати, що App Router новіший і базується на Server Components; деталі легасі спитають лише там, де на ньому реально працюють.
  • Внутрішню механіку збірки – якщо ти не подаєшся на роль в інфраструктурній команді.

Інвестуй час у розуміння критеріїв вибору (яка стратегія рендерингу і чому, що серверне, а що клієнтське) – саме це перевіряють. База залишається базою: без впевненого React жодні знання фреймворка не врятують, тому спершу пройдись по гайду підготовки до React-співбесіди, а архітектурний рівень аргументації – у статті про React-архітектуру для Senior.