Почему мы строим всё на Next.js и edge-инфраструктуре

Мы перепробовали много стеков. После более чем 40 продакшен-сайтов и приложений мы сошлись на Next.js, развёрнутом на edge, как дефолтном выборе. Вот логика, включая компромиссы.

Почему Next.js

Next.js даёт возможность выбирать правильную стратегию рендеринга для каждого маршрута — статическая генерация, серверный рендеринг или клиентский — без смены фреймворка.

Для маркетингового сайта большинство страниц статичны. Блог генерируется статически. Эндпойнт контактной формы рендерится на сервере. Интерактивное демо рендерится на клиенте. Один фреймворк закрывает всё это.

App Router (появился в v13, зрелый с v15) приносит React Server Components: Вы можете получать данные на сервере и отправлять клиенту нулевое количество JavaScript для компонентов, не требующих интерактивности. Контент-тяжёлая страница, раньше выкатывавшая 200 КБ JS, теперь выкатывает 15 КБ.

Почему edge

Традиционные серверы работают в одном регионе. Пользователь из Сингапура, обращающийся к серверу в us-east-1, добавляет 200–300 мс сетевой задержки на каждый запрос ещё до того, как сервер начал обработку.

Edge-runtime — Vercel Edge Functions, Cloudflare Workers — запускают Ваш код в более чем 30 локациях по миру. Сервер всегда близко к пользователю. TTFB стабильно меньше 50 мс по всему миру.

Компромисс: edge-runtime ограничены. Нет доступа к файловой системе, лимитированные Node.js API, меньшие лимиты памяти. Это вынуждает архитектурную дисциплину: stateless-функции, данные, забираемые через API или из edge-кэшированных баз.

Полный стек

• Фреймворк: Next.js (App Router)
• Стилизация: Tailwind CSS v4
• База данных: Postgres на Neon (serverless, edge-совместимый) или Supabase
• Аутентификация: Clerk или next-auth — в зависимости от сложности
• Email: Resend
• Платежи: Stripe
• CMS: MDX-файлы в репозитории для контент-тяжёлых сайтов; Sanity — для контента, редактируемого клиентом
• Деплой: Vercel

Что мы не используем

Мы не используем клиентский рендеринг для страниц, которым он не нужен. Мы не используем REST API там, где проще server action или RSC-запрос данных. Мы не добавляем бэкенд-фреймворк, когда хватает route handlers Next.js.

Сложность множится. Каждый дополнительный сервис — это ещё одна точка отказа, ещё один слой аутентификации, ещё один деплой-пайплайн. Правильный стек — это самый простой стек, закрывающий требования.

Стройте под актуальные требования. Добавляйте сложность только когда переросли более простое решение. Это правило экономит больше времени и денег, чем любой выбор библиотеки или хостинга. И именно поэтому наш дефолтный стек остаётся стабильным на протяжении многих проектов: он не пытается быть универсальным ответом, он пытается быть минимальным ответом на конкретный класс задач.