const fastify = require('fastify')({ logger: true });
// Control total asupra stream-urilor, ideal pentru rapoarte mari
fastify.get('/api/heavy-export', async (request, reply) => {
const dataStream = getLargeDataSetFromDb();
return reply
.header('Content-Type', 'application/octet-stream')
.send(dataStream);
});
fastify.listen({ port: 3000, host: '0.0.0.0' }, (err) => {
if (err) throw err;
console.log('Serverul rulează fără overhead de frontend.');
});Am observat un trend destul de obositor în ultimii doi ani: dacă cineva pornește un proiect nou în ecosistemul JavaScript, sare direct pe Next.js fără să stea pe gânduri. E o unealtă fantastică pentru frontend, SEO și pagini de produs, dar am văzut echipe care încercau să înghesuie logica de microservicii sau job-uri de procesare în API Routes. Sincer, e ca și cum ai încerca să cari mobilă cu o mașină de Formula 1; e rapidă, dar n-are portbagaj și te costă o avere întreținerea.
Nu mă înțelegeți greșit, folosesc Next.js zilnic, dar am învățat pe pielea mea unde se oprește utilitatea lui. Dacă ai nevoie de un API intern sau de un serviciu care stă în spatele altor aplicații, framework-ul ăsta devine brusc o piatră de moară de care nu ai nevoie.
Microserviciile și limitările runtime-ului
Recent, la un proiect cu vreo 8k useri activi simultan, aveam un serviciu de generare de PDF-uri și rapoarte financiare. Inițial, echipa l-a pus într-un API Route în Next. Ne-am lovit imediat de problema timeout-urilor. Dacă ești pe Vercel, ai limite stricte (10-60 de secunde pe planurile uzuale), iar dacă îl hostezi tu pe Docker, tot te bați cu overhead-ul de routing din Next care nu e optimizat pentru throughput masiv de date brute.
Am mutat totul într-un container separat cu Fastify. Rezultatul? Am scăzut latența la răspuns cu aproape 40% și am redus consumul de RAM de la 1.2GB la vreo 300MB în idle. Fastify sau Express îți dau control total asupra instanței. Vrei să schimbi body parser-ul? Vrei un stream direct de la baza de date către client fără să treacă prin abstractizările de Request/Response ale Next? În Node pur e o linie de cod, în Next e o luptă cu framework-ul.
Job Processors și procese de lungă durată
Next.js este, prin definiție, efemer. E gândit să primească un request, să randeze ceva și să închidă conexiunea. Dacă ai nevoie de BullMQ sau vrei să procesezi cozi de mesaje de la un RabbitMQ, Next e alegerea greșită.
Am pățit-o la un startup unde încercau să ruleze workerii de cozi direct în procesul de Next. La fiecare deploy (care se întâmpla des), toate job-urile active primeau SIGTERM pentru că Next își restarta serverul intern de randare. Un server Node dedicat, gestionat cu PM2 sau rulat în Kubernetes ca un deployment separat, îți oferă stabilitate. Poți să faci graceful shutdown cum trebuie, să aștepți să se termine procesările și să monitorizezi event loop-ul fără zgomotul de fundal de la Webpack sau TurboPack.
Trade-off-ul sincer
Next.js strălucește când ai nevoie de integrare strânsă între UI și date (Server Components sunt geniale aici). Dar dacă proiectul tău nu are un frontend propriu sau dacă API-ul este consumat de alte servicii, Next îți aduce doar complexitate inutilă. Pierzi accesul facil la sockets (da, știu că există workaround-uri, dar sunt mizerabile), pierzi controlul fin pe middleware-ul de autentificare și te trezești cu un bundle de producție uriaș pentru ceva ce ar fi putut fi un script de 50 de linii.
În concluzie, dacă faci un dashboard, mergi pe Next. Dacă faci un serviciu care procesează date în spate, un API intern sau orice are nevoie de conexiuni persistente, un server Node chior cu Fastify sau NestJS (dacă îți place arhitectura solidă) te va scăpa de multe nopți pierdute.
Voi ce folosiți pentru serviciile de „back-of-the-backend”? Mai are loc Express în 2024 sau ați trecut toți pe Bun/Hono?