import Fastify from 'fastify';
import websocket from '@fastify/websocket';
const fastify = Fastify({ logger: true });
fastify.register(websocket);
// Un server separat ne permite să gestionăm conexiuni persistente
// fără să ne facem griji de timeout-urile din Next.js sau serverless
fastify.register(async function (fastify) {
fastify.get('/ws', { websocket: true }, (connection, req) => {
connection.socket.on('message', message => {
fastify.log.info(`Received: ${message}`);
connection.socket.send('pong');
});
});
});
fastify.listen({ port: 3001 });Să fim sinceri, Next.js a devenit ciocanul cu care mulți developeri bat toate cuiele din web development. E excelent pentru SSR, SEO și rute simple de API, dar când îl pui să facă treaba unui server de backend adevărat, începe să scârțâie serios. Am văzut destule proiecte unde s-a mers pe Next.js "pentru că e simplu" și s-a ajuns la dureri de cap mari când aplicația a început să crească.
Nu mă înțelege greșit, îmi place Next.js. Dar are un scop precis. Când încerci să-l transformi în procesator de joburi sau API de microserviciu, tragi de el într-o zonă pentru care nu a fost proiectat.
Capcana API Routes din Next.js
Am avut cazul unui proiect cu vreo 15.000 de useri activi unde trebuia să generăm rapoarte PDF mari și să trimitem mail-uri în batch. Inițial, echipa a pus totul în API routes în Next.js, rulat pe un VPS clasic. Ce s-a întâmplat? Când trei useri generau rapoarte simultan, event loop-ul din Node se bloca complet. Fiindcă Next.js rula și serverul de pagini și API-ul în același proces, tot site-ul devenea inutilizabil timp de 10-15 secunde.
Next.js e gândit ca un BFF (Backend-for-Frontend). Ciclul lui de viață e optimizat pentru request-uri scurte: primești request-ul, iei datele din DB, le trântești în pagină și gata. Dacă ai nevoie de procesări grele, Next.js te încurcă.
Când e momentul să separi backend-ul?
Din experiența mea, sunt trei scenarii clare în care trebuie să scrii un server de Node.js separat (de preferat cu Fastify sau măcar Express):
- Procesare de job-uri și cozi (BullMQ / RabbitMQ): Un server Next.js nu ar trebui să ruleze workeri în fundal. Next.js are un mecanism de auto-serverless (pe platforme gen Vercel) sau de rebuild-uri frecvente la deploy. Dacă ai un worker de BullMQ care rulează în același proces cu Next.js, la fiecare deploy de frontend o să omori joburile active.
- WebSockets și conexiuni persistente: Next.js nu suportă nativ WebSockets în modul serverless și e extrem de greu de gestionat chiar și pe un server Node clasic din cauza modului în care își face routing-ul intern. Un server separat de Fastify cu
@fastify/websocketrezolvă asta în 10 linii de cod. - Microservicii cu trafic intens: Dacă ai un endpoint apelat de alte servicii de 100 de ori pe secundă, nu vrei ca acel trafic să treacă prin middleware-urile și overhead-ul de routing din Next.js. Am optimizat un endpoint de tracking mutându-l din Next.js într-un microserviciu Fastify și am obținut o reducere de 35% a timpului de răspuns și un consum de memorie mult mai stabil.
Trade-off-ul sincer
Nimic nu e gratis pe lumea asta. Când separi backend-ul, pierzi confortul de a avea totul într-un singur loc.
Trebuie să configurezi CORS, să gestionezi două deployment-uri diferite în loc de unul singur și să partajezi manual tipurile de TypeScript între frontend și backend (deși aici te ajută mult un monorepo cu Turborepo). De asemenea, pierzi simplitatea de a scrie cod direct în Server Actions.
Dar pentru orice proiect care trece de faza de MVP, această separare îți oferă liniște sufletească. Poți să scalezi doar backend-ul când ai nevoie de mai multă putere de calcul, fără să-ți pese de build-ul de frontend.
Voi cum procedați la proiectele medii și mari? Împingeți Next.js până la limită cu Server Actions și API routes sau preferați să rupeți backend-ul într-un serviciu separat din prima zi?