Next.js: настройка проекта, маршруты и первая архитектура

Эта статья продолжает цикл «Next.js: с нуля до высоконагруженного веб-сервиса». В первой статье мы разобрали, что такое Next.js и зачем он нужен. Теперь переходим к первому инженерному решению: как устроить проект так, чтобы он пережил не только демо, но и рост команды, фич и нагрузки.

Где место Next.js в архитектуре

Next.js удобно рассматривать не как «React с роутингом», а как boundary между пользовательским интерфейсом, серверной логикой и инфраструктурой доставки. В одном приложении могут жить страницы, серверные компоненты, route handlers, server actions, метаданные, sitemap и логика кеширования.

На старте важно решить, что Next.js будет делать сам, а что останется во внешних сервисах. Для личного сайта он может быть почти всем веб-слоем. Для продукта с доменной логикой лучше держать тяжелую бизнес-логику в отдельном backend/API, а Next.js использовать как BFF и слой рендера.

Старт проекта

npx create-next-app@latest web --ts --eslint --app
cd web
npm run dev

Для новых проектов разумно выбирать App Router. Он задаёт современную модель: server components по умолчанию, nested layouts, route groups, loading/error boundaries и colocated data fetching.

Структура директорий

src/
  app/
    (marketing)/
      page.tsx
    dashboard/
      layout.tsx
      page.tsx
      loading.tsx
      error.tsx
    api/
      health/route.ts
  components/
    ui/
    features/
  lib/
    api.ts
    auth.ts
    cache.ts
  config/
    env.ts

Папка app отвечает за маршруты и композицию экранов. Переиспользуемые компоненты лучше выносить отдельно. Всё, что связано с доступом к данным, окружением, кешем и интеграциями, держите в lib или feature-модулях, а не размазывайте по page.tsx.

Route groups и layouts

Route groups помогают отделить URL от внутренней организации. Например, (marketing) не появится в адресе, но позволит держать лендинги отдельно от кабинета. Layouts задают постоянные части интерфейса: навигацию, sidebar, providers, shell приложения.

Главное правило: layout не должен становиться складом всего проекта. Если в нём появляется бизнес-логика, сложные запросы и условные сценарии, это сигнал выделить feature-компонент или отдельный server component.

Server и Client Components

По умолчанию компоненты в App Router серверные. Это хорошо: меньше JavaScript уходит в браузер, можно безопасно читать cookies, обращаться к базе или backend API. Client Components нужны только там, где есть состояние в браузере, события, эффекты или доступ к DOM.

// Server Component
export default async function Page() {
  const profile = await getProfile();
  return <ProfileView profile={profile} />;
}

// Client Component
'use client';

export function ProfileTabs() {
  const [tab, setTab] = useState('activity');
  return <Tabs value={tab} onChange={setTab} />;
}

Что заложить сразу

• Единый слой работы с env-переменными, чтобы не ловить undefined в production.
• Health endpoint для мониторинга контейнера или платформы.
• Разделение публичных и приватных маршрутов.
• Понятные правила кеширования данных.
• Базовые метаданные, sitemap и robots.txt.

Итог

Хороший стартовый Next.js-проект — это не максимальная абстракция, а ясные границы. App Router отвечает за маршруты и рендер, lib — за интеграции и инфраструктурные функции, feature-компоненты — за пользовательские сценарии. В следующей статье цикла разберём рендеринг, кеширование и ISR: именно там Next.js начинает отличаться от обычного React-приложения по-настоящему.