const fastify = require('fastify')({ logger: true });
const { Queue } = require('bullmq');
const emailQueue = new Queue('emails', {
connection: { host: '127.0.0.1', port: 6379 }
});
// Webhook ultra-rapid izolat complet de serverul web principal
fastify.post('/api/webhook', async (request, reply) => {
const { userId, event } = request.body;
// Punem jobul în coada Redis și eliberăm conexiunea imediat
await emailQueue.add('sendWelcome', { userId, event });
return { success: true };
});
const start = async () => {
try {
await fastify.listen({ port: 3001, host: '0.0.0.0' });
} catch (err) {
fastify.log.error(err);
process.exit(1);
}
};
start();Văd tot mai des tendința de a înghesui absolut toată logica de business în API routes-urile din Next.js. E la îndemână. Scrii TypeScript peste tot, ai deployment cu un singur click și gata, ai scăpat de bătăi de cap. Dar la un moment dat, abordarea asta se lovește violent de realitate.
Am avut un caz acum doi ani, la un proiect care ajunsese la vreo 15.000 de useri activi pe zi. Aveam un Next.js care se ocupa și de UI, și de niște integrări cu API-uri externe, și de un queue de emailuri cu BullMQ. Rezultatul? Serverul Node din spate mânca peste 1.5 GB de RAM și din când în când procesele mureau inexplicabil în PM2 din cauza out-of-memory. Atunci ne-am așezat la masă și am tras o linie clară între ce înseamnă BFF (Backend for Frontend) și ce înseamnă un backend adevărat.
Când Next.js devine o povară
Next.js a fost gândit ca un framework de frontend cu capabilități de server-side rendering și un strat subțire de API. Nu e un înlocuitor de NestJS, Fastify sau Express pentru backend-ul greu.
Dacă ai una dintre următoarele situații, e momentul să scoți codul din Next.js:
- Job-uri pe fundal și cozi de mesaje. Dacă folosești BullMQ sau ai procese care rulează la fiecare 5 minute pentru sync de date, nu le pune în Next. Nu vrei ca un job intens de procesare să blocheze event loop-ul serverului care livrează paginile web către utilizatori.
- WebSockets și conexiuni persistente. Next.js pe Vercel rulează serverless, unde WebSockets sunt practic imposibile fără un serviciu terț. Chiar și pe un VPS propriu, Next.js nu e optimizat să țină mii de conexiuni TCP deschise. Un server simplu de Fastify consumă de trei ori mai puține resurse pentru asta.
- Microservicii interne. Dacă ai un serviciu care doar procesează plăți sau trimite notificări și e apelat doar de alte servere, n-ai niciun motiv să cari după tine tot runtime-ul de Next.js, care are un build-time uriaș.
Trade-off-ul sincer
Evident, dacă separi serviciile, pierzi din simplitate. Monolitul Next.js e extrem de ușor de gestionat la început.
Când separi un server de Node, ai brusc două repo-uri (sau un monorepo complex), două pipeline-uri de deployment, CORS de configurat și share-ul de tipuri TypeScript devine mai greoi. Dar beneficiul e uriaș: noi am redus consumul de RAM cu 60% și am stabilizat complet aplicația după ce am mutat procesatorul de joburi într-un container separat de Docker.
Voi unde trageți linia? Folosiți Next.js strict pentru frontend sau împingeți limitele lui până când crapă?