Як я використовую Next.js у роботі

2026-09-10

Next.js - мій дефолт для вебпродуктів, і не тому, що це модно. Він дає одній TypeScript-кодовій базі покрити те, що раніше було трьома проєктами: маркетинговий сайт, який має ранжуватись, застосунок за логіном і тонкий шар API між ними. Цей сайт - маленький приклад: локалізовані роути, згенеровані метадані, sitemap, Open Graph-зображення й роут llms.txt, усе в одному проєкті на App Router.

Починаю з сервера. Сторінки й лейаути за замовчуванням - Server Components: вони беруть дані поруч із базою, віддають HTML замість JavaScript-бандла й тримають секрети на сервері. «use client» ставлю лише на листки дерева, яким потрібні стан, ефекти чи браузерні API, - форма, дропдаун, мапа. Коли дерево починається з «use client» на самому верху, за цим зазвичай ідуть важкий бандл і цілий клас багів.

Вибір режиму рендерингу - продуктове рішення, а не технічне. Статична генерація для сторінок, які змінюються з деплоєм. ISR або ревалідація за тегами для каталогів, оголошень і блогів, що змінюються протягом дня, - revalidateTag після запису, а не таймер, якого ніхто не розуміє. Динамічний рендеринг зі стрімінгом через Suspense для дашбордів і всього персонального, щоб каркас з’являвся миттєво, а повільні дані догружались. Для кожного роуту записую, чому він статичний чи динамічний; цей один рядок потім економить тиждень питань «чому ціна застаріла?».

Для мутацій використовую Server Actions у формах, що належать сторінці, і Route Handlers, коли в застосунок має звертатись щось ззовні: вебхуки від платіжного провайдера чи Telegram, мобільний клієнт, cron. В обох випадках вхідні дані валідуються Zod на сервері, авторизація перевіряється на сервері, і клієнт ніколи нічого не вирішує щодо грошей чи прав. У більших продуктах Next.js лишається фронтендом і BFF, а основний домен живе в сервісі на NestJS чи Node.js з власною базою.

Продуктивність і SEO - частина definition of done. next/image зі справжніми розмірами, next/font, щоб прибрати стрибки верстки, generateMetadata і структуровані дані на кожній публічній сторінці, динамічні імпорти для важких віджетів і Core Web Vitals, перевірені на середньому телефоні, а не на MacBook. Деплой - або Vercel, коли команда хоче нуль ops, або standalone-збірка в Docker на AWS чи VPS, коли важать вартість, місце зберігання даних чи довгі задачі.

Що відмовляюсь робити: «use client» на кореневому лейауті, ті самі дані, які тягнуть п’ять компонентів без жодної думки про кеш, бізнес-логіку, заховану в middleware, і оновлення мажорної версії в п’ятницю без читання codemod-ів. Якщо ваш Next.js-застосунок здається повільним чи крихким - надішліть репозиторій і дві найповільніші сторінки. Відповім, що б я переніс на сервер, що закешував і що видалив.

Дайте наступному продукту того, хто лишається.

Готовий стартувати зараз і лишитись. Довготермінові ретейнери, не злив за два тижні. Напишіть - обговоримо проєкт, вимоги і як рухатись далі.

Запитайте про досвід чи послуги