nextjs-template/ai/nextjs-style-guide/data/index.md

title, description, keywords

title	description	keywords
Источники данных	Какие источники данных используются в проекте и как с ними работать.	данные api rest realtime клиент swr infrastructure введение карта раздела

Источники данных

Какие источники данных используются в проекте и как с ними работать.

Принципы раздела

• Клиент — в infrastructure/. Каждый внешний сервис — отдельный модуль слоя infrastructure/{service-name}/.
• Прямой fetch запрещён. Запросы идут только через клиент модуля. Исключения — точечные и обоснованные.
• Источник данных диктует канал. REST, realtime и т.п. — независимые подразделы, у каждого своя модель клиента и своё потребление.
• Серверные и клиентские компоненты потребляют по-разному. Server Components — прямой await метода клиента, клиентские — через готовые GET-хуки REST-клиента (useGetUserList, useGetPostDetail и т.п.). SWR инкапсулирован в хуке, компонент про него не знает.

Карта раздела

REST

Канал «запрос-ответ» по HTTP. Покрывает большинство API.

• REST — обзор раздела: создание клиента и использование.
• Создание клиента — как оформляется REST API в проекте:
  • Обзор — когда нужен клиент и как выбрать подход.
  • Автогенерация из OpenAPI — для API с OpenAPI-спецификацией, через @gromlab/api-codegen.
  • Ручное создание — для API без схемы, клиент пишется и поддерживается руками.
  • GET-хуки REST-клиента — прозрачные SWR-обёртки над GET-методами клиента.
• Использование — как получать данные через готовый клиент:
  • Стратегии получения данных — как выбрать способ получения данных под ситуацию.
  • Серверный await — прямой await метода клиента в Server Components.
  • Параллельные серверные запросы — запуск независимых серверных запросов без waterfall.
  • Передача промиса ниже — серверный стриминг через промис и Suspense.
  • Начальные данные для клиентских хуков — серверный промис в SWRConfig fallback.
  • Клиентский GET-хук — получение данных в Client Components через готовый GET-хук.
  • Business-композиция — доменная интерпретация и композиция REST-данных.

Realtime

Канал push-данных: WebSocket, SSE, событийные шины. Транспорт не зашит в правила — важна абстракция «подписка».

• Realtime — клиент realtime в infrastructure/, потребление через useSWRSubscription или прямые подписки.

Что даёт раздел

После прочтения раздела понятно:

• Где живёт код работы с API и почему именно там.
• Когда генерировать клиент автоматически, а когда писать вручную, и как структурирован каждый из вариантов.
• Какие GET-хуки относятся к REST-клиенту и почему они живут в infrastructure/{service-name}/hooks/.
• Как выбрать стратегию получения REST-данных под конкретную ситуацию.
• Как подключать realtime-источники в общую модель работы с данными.
• Какие правила обязательны и какие отклонения допустимы.

Что не входит в раздел

• Глобальное состояние UI — Stores, формы, фичефлаги. Это Stores.
• Доменная логика — как данные превращаются в сценарии бизнеса. Это слой business/ в Архитектуре.
• Хуки общего назначения — переиспользуемые хуки UI, не привязанные к конкретному API. Отдельный прикладной раздел для них пока не ведётся.