Next.js-приложение в продакшен

До любого кода реши две вещи, которые формируют всё дальше: как ключуется тенантность и как рендерится каждый роут. Выбери поддомен-на-тенанта (чистая изоляция, больше работы с DNS/сертификатами) против пути-на-тенанта (проще роутинг, легче утечь) и выпиши правило ключевания. Затем классифицируй каждый роут по стратегии рендера — статика (SSG) для маркетинга, ISR для опубликованного контента тенанта, динамический SSR для дашбордов — потому что эта классификация определяет твой кэш, твой раздел edge/node и радиус поражения позже. Выпиши 2–3 SLO (например, p75 LCP < 2.5 с на опубликованных страницах, p99 TTFB < 200 мс для кэшированных роутов) и явные non-goals, чтобы не вылизывать редактор, когда трафик несёт путь чтения.

Подними скелет App Router с осознанно проведённой границей server/client. Держи получение данных в Server Components, чтобы креды и запросы не попадали в клиентский бандл; вынеси интерактивность в маленькие клиентские острова на листьях, а не в постраничный 'use client'. Проводи мутации через Server Actions, а не самописные route handlers для отправки форм, и обращайся к слою данных (ORM/SQL в RSC) прямо в дереве компонентов. Проверка хорошего скелета: опубликованная страница везёт почти нет JS, а граница гидратации — тонкая оболочка вокруг интерактивных кусков, а не вокруг страницы.

Сделай мультитенантную авторизацию герметичной. Реши session или JWT для своего случая (stateful-сессии отзываются мгновенно, но нужен стор; JWT масштабируются без состояния, но отзыв и ротация на тебе), затем форси границу тенанта на слое данных, чтобы каждый запрос скоупился по id тенанта — никогда не верь одному лишь поддомену. Помечай server-only-модули, чтобы секрет нельзя было импортнуть в клиентский компонент, держи URL базы и ключи подписи вне бандла и защищай Server Actions от CSRF и от действий над ресурсами чужого тенанта. Граница, которую ты доказываешь: залогиненный пользователь тенанта A не может прочитать, изменить или даже прозондировать тенанта B, что бы он ни положил в запрос.

Сочетай три кэша, не утекая данные тенанта и не отдавая навсегда устаревший контент. Используй ISR (Full Route + Data Cache), чтобы опубликованные страницы тенанта были статически-быстрыми с фоновой ревалидацией; поставь CDN впереди, чтобы кэшированный HTML отдавался с edge; и тегируй записи кэша по доменам (например, tenant:{id}, post:{id}), чтобы одно редактирование инвалидировало ровно те страницы, что оно затронуло, через on-demand revalidation — не глобальный purge, не устаревшую страницу. Ловушка — общий ключ кэша: если CDN или Data Cache ключуется по URL, но не по тенанту, запрос может вернуть HTML чужого тенанта. Сделай тенанта частью каждого ключа кэша и докажи, что инвалидация хирургична.

Размести каждый кусок работы на правильном рантайме и держи страницу лёгкой. Edge-рантайм быстро стартует и близок к пользователю, но у него урезанная поверхность API и нет нативных Node-модулей — он подходит для роутинга тенантов, middleware-проверки авторизации и геолокационных rewrite'ов; node подходит для ORM, тяжёлой криптографии и всего, что тянет Node-билтины. Положи резолв тенанта и дешёвый auth-гейт в middleware на edge; держи работу с БД на node. Затем задай бюджет ассетов — оптимизируй картинки через next/image, сабсеть и self-host шрифты, чтобы убить layout shift, и анализируй бандл, чтобы случайный клиентский импорт не разнёс твой JS-бюджет. Цель: опубликованная страница под заданным JS-бюджетом (например, < 100 КБ gzip) с корректно отмасштабированной LCP-картинкой.

Сделай отказ локализованным, а работающее приложение читаемым. Построй иерархию error.tsx / not-found.tsx, чтобы брошенная ошибка в одном сегменте роута деградировала это поддерево, а не всё приложение — падающий виджет в дашборде тенанта A не должен гасить тенанта B. Затем инструментируй: зарегистрируй OpenTelemetry через instrumentation.ts, снимай RED-метрики (rate, errors, duration) на путях чтения и действий, логируй структурные серверные события, запрашиваемые по тенанту, и пробрасывай трейсы через переходы RSC → слой данных, чтобы медленная страница указывала на медленный span. Преврати свои SLO в дашборд с error budget, чтобы видеть инцидент раньше, чем следующий этап его тебе вручит.

Выкати так, как ты бы это эксплуатировал для тенантов. Выбери self-host или managed-платформу с открытыми глазами — managed даёт ISR/CDN/edge бесплатно, но биллит за инвокацию и за GB-отдачи; self-host на node даёт контроль, но стор кэша и обвязка CDN на тебе. Что бы ты ни выбрал, реши проблему serverless-БД: шторм соединений на инвокацию исчерпает Postgres, поэтому поставь пулер (PgBouncer или data-proxy платформы) между приложением и БД. Собери пайплайн, гейтящийся на тесте изоляции тенантов из этапа авторизации, держи секреты инжектируемыми при деплое и сделай плохую выкатку откатываемой за секунды.

Запрос с незаключённым в ключ заголовком (или тенант-слепым ключом кэша) заставляет Next.js закэшировать неправильный ответ в общую запись ISR/CDN; теперь тенанту B отдаётся HTML тенанта A — или подконтрольная атакующему страница — пока запись не ревалидируется, а параллельный шторм холодных стартов при ревалидации взвинчивает TTFB. Обнаружь это по своим метрикам (скачок кросс-тенантных 200, всплеск TTFB на ревалидации), смягчи вживую (вычисти отравленный тег, сузь ключ кэша, выбрось незаключённый вход), найди корневую причину и напиши пост-мортем. Держащийся фикс — ключевать кэш по всему, что варьирует ответ: тенант, состояние авторизации, заголовки, которые ты реально читаешь, — плюс коалесценция запросов на ревалидации, чтобы холодная ISR-запись не вызвала thundering herd. «Укоротить TTL» — не фикс; это лишь сужает окно отравления.