const fastify = require('fastify')({ logger: true });
const Bull = require('bull');
// Coadă Redis pentru procesare asincronă, imposibil de rulat stabil în Serverless Next.js
const reportQueue = new Bull('pdf-reports', 'redis://127.0.0.1:6379');
fastify.post('/api/v1/generate-report', async (request, reply) => {
const { userId, reportType } = request.body;
// Adăugăm job-ul în coadă și răspundem instant clientului
await reportQueue.add({ userId, reportType }, { attempts: 3, backoff: 5000 });
return { status: 'accepted', message: 'Raportul se procesează în fundal.' };
});
const start = async () => {
try {
await fastify.listen({ port: 3001, host: '0.0.0.0' });
} catch (err) {
fastify.log.error(err);
process.exit(1);
}
};
start();Am văzut în ultima vreme o tendință destul de ciudată în comunitate: lumea tinde să arunce Next.js peste orice problemă, de parcă ar fi un panaceu. Ai de făcut un landing page? Next.js. Un dashboard? Next.js. Un API intern sau un procesator de cozi? Tot Next.js, că "are API routes și e simplu".
Este o greșeală care te va costa timp și bani. Am pățit-o acum un an la un proiect cu vreo 12.000 de utilizatori activi, unde am decis inițial să înghesuim toate procesările de rapoarte PDF în API-ul din Next.js. Rezultatul? Serverless-ul dădea timeout constant pe Vercel, iar când am mutat pe instanță proprie, Node-ul murea sufocat de consumul de memorie.
Hai să vedem unde se rupe filmul și când trebuie să pui piciorul în prag și să ridici un server separat de Node.js (cu Fastify sau Express).
1. Job-uri de fundal și procese de lungă durată
Next.js este gândit pe modelul request-response rapid. Serverless-ul sau funcțiile edge au limite stricte de execuție (de obicei între 10 și 30 de secunde pe majoritatea platformelor de hosting cloud).
Dacă ai de generat rapoarte masive, de procesat imagini, de trimis newslettere în masă sau de rulat sincronizări cu API-uri terțe, Next.js te va lăsa în drum. Ai nevoie de un proces care rulează continuu (un daemon). Un server Node simplu, rulat frumos cu PM2 pe un VPS, poate gestiona cozi (folosind BullMQ și Redis) fără să aibă grija timeout-urilor.
2. WebSockets și conexiuni persistente
Dacă aplicația ta are nevoie de chat în timp real, notificări push instant sau colaborare live (gen Google Docs), Next.js devine extrem de greoi. Da, poți face un workaround pe un server custom de Express cu Next.js integrat, dar strici tot farmecul framework-ului și pierzi optimizările de deploy.
Un server separat de Node.js cu socket.io sau ws este mult mai curat. Îl scalezi independent, îl pui în spatele unui Nginx și nu încurci traficul de web-rendering cu conexiunile deschise de WebSocket.
3. Microservicii interne și consumul de resurse
Next.js vine la pachet cu mult "overhead" (compilare, routing complex, optimizări de imagini). Dacă ai nevoie doar de un API intern care vorbește cu baza de date sau face niște calcule, Next.js este o risipă masivă de resurse.
Am avut un caz unde am rescris un serviciu intern de traduceri din Next.js API în Fastify pur. Am economisit cam 30% la build time în CI/CD și am redus consumul de memorie RAM de la 450MB la doar 60MB per instanță. Când rulezi 10 instanțe în Kubernetes, diferența asta se simte direct în factura de AWS.
Trade-off-ul sincer
Să fim realiști, există și un preț de plătit. Când separi backend-ul de frontend, pierzi avantajul monorepo-ului simplu unde partajezi tipurile de TypeScript direct între client și server (deși poți rezolva asta cu un monorepo real cu Turborepo). De asemenea, ai de configurat CORS, de gestionat două deploy-uri diferite și de configurat securitatea pe două fronturi.
Pentru un MVP sau un proiect unde backend-ul doar trimite 3 JSON-uri amărâte din baza de date, Next.js API routes este perfect. Rămâi acolo.
Dar când baza de date începe să transpire, când ai nevoie de cron-uri reale sau când vrei să controlezi la milisecundă event loop-ul din Node, fă-ți un serviciu și scrie un server de Fastify curat, pus sub supravegherea PM2.
Voi cum ați împărțit arhitectura la proiectele voastre recente? Ați regretat că ați mers pe Next.js all-in?