Next.js Middleware — потужний механізм, який дозволяє виконувати код на межі (edge) перед тим, як запит досягне потрібної сторінки або API Route. Завдяки цьому ми можемо реалізовувати авторизацію, логін, перенаправлення чи модифікацію заголовків у реальному часі, і все це з мінімальними затримками. У цій статті розглянемо, як працює Middleware у Next.js «під капотом», які має наслідки для продуктивності, як впливає на безпеку та які пастки найчастіше зустрічаються у командах, що впроваджують його у продакшн.
Як працює Middleware у Next.js
З версії 12 Next.js впровадив підтримку Edge Runtime, тобто середовища виконання коду в мережі CDN (наприклад, Vercel Edge Network). Middleware компілюється в Edge Functions і запускається в найближчому мережевому вузлі щодо клієнта. Завдяки цьому час реакції обмежений кількома мілісекундами, а одночасно ми маємо доступ до повного об’єкта Request та Response, сумісного з Web Standard API.
// middleware.ts
import { NextResponse } from 'next/server';
export function middleware(request) {
const url = request.nextUrl;
if (url.pathname.startsWith('/admin') && !request.cookies.get('auth')) {
return NextResponse.redirect(new URL('/login', request.url));
}
return NextResponse.next();
}
У наведеному прикладі код виконується при кожному запиті, а рішення про перенаправлення приймається ще до того, як запит досягне шару застосунку. Middleware визначається в каталозі pages або app як файл middleware.ts і автоматично застосовується до всіх маршрутів, якщо не обмежити їх за допомогою matcher у next.config.js.
Архітектура та вартість виклику
Edge Functions ізольовані в контейнерах типу V8 Isolate, що означає, що вони не мають доступу до Node.js API (наприклад, fs). Кожен виклик вимагає:
- десеріалізації запиту в об’єкт
Request, - виконання JavaScript‑коду (або TypeScript після транспіляції),
- серіалізації можливої відповіді.
На практиці вартість запуску є сталою — приблизно 0,5‑1 ms для простого умови, але зростає лінійно зі збільшенням кількості операцій I/O (наприклад, читання з cookies, виклики fetch до зовнішніх сервісів). Тому ключове — мінімізувати логіку в Middleware.
Next.js Middleware і безпека
Розміщуючи логіку безпеки на шарі edge, ми отримуємо дві важливі переваги: (1) атакувальник не доходить до сервера застосунку, і (2) можемо примусово застосовувати політики CSP або HSTS перед рендерингом. Однак, оскільки код працює в обмеженому середовищі, ми не маємо доступу до традиційних криптографічних бібліотек — доводиться покладатися на вбудовані функції crypto.subtle або зовнішні сервіси.
«Безпека в Middleware — це не лише блокування неавторизованих запитів, а й зменшення поверхні атаки шляхом виконання перевірок якомога ближче до користувача.»
Найважливіші практики:
- Валідуйте всі заголовки та вхідні параметри — edge не знає типів.
- Використовуйте короткоживучі токени (наприклад, JWT з коротким TTL), щоб уникнути необхідності довготривалого зберігання сесії в пам’яті.
- Не логуйте чутливі дані в Middleware — логи зберігаються в CDN і можуть бути доступні ширше.
Оптимізація Middleware у застосунку Next.js
Оптимізація починається з обмеження області дії. matcher дозволяє вказати, які шляхи підпадають під Middleware, що зменшує кількість викликів. Приклад конфігурації:
// next.config.js
module.exports = {
async redirects() {
return [];
},
middleware: {
matcher: ['/admin/:path*', '/api/protected/:path*']
}
};
Крім того, варто уникати дорогих операцій fetch у Middleware. Якщо необхідно отримати дані, розгляньте їх кешування в Edge Config або в CDN. Приклад простого кешу:
export async function middleware(request) {
const cacheKey = `user-${request.cookies.get('auth')}`;
const cached = await caches.default.match(cacheKey);
if (cached) return NextResponse.next();
// ...fetch user profile
}
Пам’ятайте, що Edge Cache має обмеження розміру (до 5 MB) і TTL (максимум 30 днів). Тому кешувати можна лише невеликі, незмінні фрагменти.
Коли використовувати Middleware, а коли ні
Middleware ідеально підходить у сценаріях, які вимагають швидкого рішення перед рендерингом: авторизація, гео‑таргетинг, A/B тестування, модифікація заголовків. Однак це не заміна повноцінних API Routes, коли потрібні:
- операції з базою даних з високою затримкою,
- обробка файлів, стрімінг або великі payload’и,
- тривалі процеси (наприклад, генерація PDF).
У таких випадках краще скористатися API Routes, які працюють у традиційному середовищі Node.js runtime і дають повний доступ до серверного середовища.
Checklist: Безпечне впровадження Middleware у продакшн
- ✅ Визначте точний
matcher– обмежте виклики лише необхідними шляхами. - ✅ Уникайте синхронних
fetch– якщо потрібно, впровадьте кеш. - ✅ Валідируйте та санітуйте всі вхідні дані.
- ✅ Моніторте час виконання (наприклад, за допомогою Vercel Analytics) – ціль < 5 ms.
- ✅ Тестуйте у режимах
developmentтаpreviewперед продакшном. - ✅ Не зберігайте секретні ключі у коді – використовуйте змінні середовища, доступні в Edge Runtime.
Типові помилки та компроміси
Однією з найпоширеніших помилок є розміщення у Middleware дорогої бізнес‑логіки, що призводить до збільшення latency та вищого споживання ресурсів edge. Іншою пасткою є залежність від глобального стану (наприклад, синглтонів) – в ізольованих інстанціях немає спільної пам’яті, тому кожен запит працює у чистому контексті.
Компроміси продуктивності:
- Зменшення кількості викликів
fetchза рахунок трохи старіших даних у кеші. - Використання простих регулярних виразів у
matcherзамість складних умов у коді.
Якщо вам потрібна більш просунута логіка, розгляньте розбиття її на два етапи: швидке рішення у Middleware та повна верифікація в API Route.
Підсумовуючи, Next.js Middleware – це потужний інструмент, який при правильній конфігурації та свідомому підході до продуктивності може значно підвищити безпеку та реактивність застосунку. Якщо ви хочете впровадити оптимальну систему Middleware у вашому проєкті, наша команда в Coderia.it допоможе вибрати архітектуру, провести аудит та забезпечити стабільність у продакшн.
