import Queue from 'bull';
import { processPdfJob } from './processors/pdf';
const pdfQueue = new Queue('pdf-generation', process.env.REDIS_URL || 'redis://127.0.0.1:6379');
// Worker dedicat, izolat complet de serverul web principal
pdfQueue.process(async (job) => {
console.log(`[Worker] Pornit jobul ${job.id} pentru user ${job.data.userId}`);
const result = await processPdfJob(job.data);
return result;
});
console.log('Worker-ul de PDF rulează separat...');Next.js a devenit un fel de standard de facto în lumea React, iar tentația de a pune totul acolo e uriașă. Am văzut echipe care își mută tot backend-ul în API routes doar pentru că "e tot JavaScript". Săptămâna trecută am mutat un procesor de joburi dintr-un Next.js într-un microserviciu Express simplu și am redus consumul de memorie de la 1.2GB la mai puțin de 150MB. Câștigi stabilitate și bani dacă știi unde să tragi linia între frontend și un backend adevărat.
Problema cu Next.js când backend-ul devine greu
Next.js e gândit în primul rând pentru livrare de pagini și un strat subțire de API (BFF - Backend-for-Frontend). Când începi să pui logică grea acolo, te lovești de limitările de arhitectură.
Am avut un proiect cu vreo 8k utilizatori activi unde un singur endpoint de export PDF, apelat destul de des, punea la pământ tot site-ul. De ce? Pentru că bloca event loop-ul din procesul Next.js care trebuia să servească și paginile de frontend. Utilizatorii primeau erori de timeout pe pagini simple doar pentru că un admin genera un raport mare.
În plus, dacă rulezi pe Vercel sau alte platforme serverless, ai o limită strictă de execuție (de obicei 10-15 secunde). Dacă baza de date e leneșă sau ai de procesat date mari, request-ul tău va muri la jumătate.
Cele trei scenarii unde un server Node separat e obligatoriu
M-am prins după câteva proiecte eșuate că e mult mai simplu să separi lucrurile când ai nevoie de:
-
Job-uri de fundal și cozi (Queue Processing): Dacă folosești BullMQ sau Bee-Queue pentru procesat task-uri asincrone, nu le pune în Next.js. Ai nevoie de un proces Node care rulează continuu, gata să preia joburi din Redis fără să fie afectat de restarturile de deployment ale frontend-ului.
-
Conexiuni persistente (WebSockets / SSE): Next.js pe serverless nu suportă WebSocket nativ. Chiar și pe un server Node clasic, să integrezi Socket.io în Next e o durere de cap la fiecare update major. Un server Fastify dedicat pe un VPS de 5 dolari poate ține mii de conexiuni deschise fără să transpire.
-
API-uri interne cu throughput mare: Dacă ai microservicii care vorbesc între ele, n-ai nevoie de overhead-ul de rutare și build pe care îl aduce Next.js. Un server Node curat pornește instant și consumă o fracțiune din resurse.
Trade-off-ul sincer: Ce pierzi dacă le separi
Ca să fim realiști, separarea înseamnă muncă în plus. Pierzi beneficiul de a avea totul într-un singur loc.
Trebuie să configurezi CORS corect (am pierdut ore bune cu asta pe vremuri), să gestionezi două deployment-uri diferite (de exemplu, Next pe Vercel și serverul Node pe Railway sau VPS cu PM2) și să partajezi manual tipurile de TypeScript. Dacă nu ai un monorepo bine pus la punct, te vei trezi scriind aceleași interfețe de două ori. Dar pentru stabilitatea producției, merită cu vârf și îndesat.
Uite o structură minimalistă pentru un worker de BullMQ rulat separat, complet izolat de frontend. Pornește în milisecunde și nu blochează nimic. Voi cum faceți, înghesuiți totul în Next sau le separați din start?