> Откуда приходят данные при серверной генерации в Next.js (JavaScript, Next.js)

Короткий ответ

Данные при серверной генерации в Next.js приходят из внешних источников: API, базы данных, файловой системы или CMS. В зависимости от стратегии рендеринга (SSG, SSR, ISR) данные загружаются на сервере через getStaticProps, getServerSideProps или в Server Components с помощью async компонентов. Next.js сам управляет временем загрузки - на этапе сборки, при каждом запросе или с ревалидацией.

Подробное объяснение

В Next.js серверная генерация означает, что HTML формируется на сервере, а не в браузере. Данные для этой генерации могут поступать из нескольких источников:

• Внешние REST/GraphQL API - через fetch или сторонние клиенты (axios, Apollo). Next.js поддерживает fetch с кэшированием по умолчанию в Server Components.
• Базы данных - напрямую из PostgreSQL, MongoDB и других, используя серверные библиотеки (например, Prisma, Drizzle). Это возможно только в серверном коде, так как клиентский код не имеет доступа к БД.
• Файловая система - чтение локальных JSON, Markdown или CSV файлов, часто используется для статических сайтов (например, блогов).
• CMS и headless платформы - Contentful, Strapi, Sanity и другие, через их SDK или API.
• Кэш и CDN - при ISR (Incremental Static Regeneration) данные могут браться из кэша Next.js после первой генерации, а обновляться по ревалидации.

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

• SSG (Static Site Generation) - getStaticProps или generateStaticParams + fetch в Server Components. Данные загружаются один раз при сборке (next build).
• SSR (Server-Side Rendering) - getServerSideProps или динамические Server Components. Данные загружаются при каждом запросе пользователя.
• ISR - как SSG, но с опцией revalidate. Данные обновляются в фоне после указанного интервала.
• Server Components (App Router) - async компоненты с прямым await fetch() или вызовом БД. Next.js автоматически определяет, когда выполнять код - на сервере.

Важно: в App Router (Next.js 13+) данные передаются через props между серверными и клиентскими компонентами. Серверные компоненты могут напрямую обращаться к БД или API без дополнительных маршрутов.

На практике

При выборе источника данных учитывай:

• Безопасность - ключи API и credentials для БД хранятся только в серверных переменных окружения (.env.local), никогда не попадают на клиент.
• Производительность - для SSG данные должны быть доступны на этапе сборки. Для SSR - быстро возвращаться, иначе TTFB (Time to First Byte) растёт.
• Кэширование - в App Router fetch по умолчанию кэширует GET-запросы. Отключай через cache: 'no-store' для динамических данных.
• Ошибки - всегда обрабатывай try/catch в серверных функциях, иначе Next.js вернёт 500 ошибку.

Типичный сценарий: для страницы товара в интернет-магазине данные приходят из БД через Prisma в getServerSideProps (если цены меняются часто) или через ISR с ревалидацией раз в минуту (если обновления редкие).

Пример кода

App Router (Server Component):

JSX
// app/products/page.js
export default async function ProductsPage() {
  // Данные из внешнего API
  const res = await fetch('https://api.example.com/products', {
    cache: 'force-cache' // для SSG
  });
  const products = await res.json();

  // Или напрямую из БД
  // const products = await db.product.findMany();

  return (
    <ul>
      {products.map(p => <li key={p.id}>{p.name}</li>)}
    </ul>
  );
}

Pages Router (SSR):

JSX
// pages/products.js
export async function getServerSideProps() {
  const res = await fetch('https://api.example.com/products');
  const products = await res.json();
  return { props: { products } };
}

Как отвечать на собеседовании

Начни с чёткого перечисления источников: API, БД, файлы, CMS. Затем объясни, как выбор стратегии (SSG/SSR/ISR) влияет на момент загрузки данных. Упомяни разницу между Pages Router и App Router - в новом подходе данные получаются прямо в компоненте без дополнительных функций. Подчеркни безопасность: credentials только на сервере. Добавь про кэширование fetch в App Router. Если спросят про производительность, скажи, что для SSG данные грузятся один раз, для SSR - каждый запрос, и это trade-off между свежестью и скоростью.

Что проверяет интервьюер

• Понимание архитектуры Next.js: различие между серверным и клиентским кодом.
• Знание стратегий рендеринга и их влияния на источник данных.
• Умение выбирать правильный метод (SSG vs SSR vs ISR) под задачу.
• Осведомлённость о безопасности (env variables, server-only code).
• Практический опыт с реальными источниками (БД, API, CMS).

Типичные ошибки

• Путаница между серверным и клиентским кодом - попытка использовать localStorage или window в серверных функциях.
• Игнорирование кэширования - неявное кэширование fetch в App Router приводит к устаревшим данным, если не указать cache: 'no-store'.
• Утечка секретов - передача API-ключей через getStaticProps в props, которые затем попадают в клиентский бандл.
• Отсутствие обработки ошибок - необработанный reject в fetch или ошибка БД ломает всю страницу.
• Неправильный выбор стратегии - использование SSR для данных, которые можно закешировать на неделю, или SSG для данных, меняющихся каждую секунду.