// ecosystem.config.js - Configurația PM2 pentru microserviciul nostru Node de procesare
module.exports = {
apps: [
{
name: 'pdf-processor-service',
script: './dist/server.js',
instances: 'max',
exec_mode: 'cluster',
autorestart: true,
watch: false,
max_memory_restart: '1G',
env: {
NODE_ENV: 'production',
PORT: 4000
}
}
]
};Am văzut în ultima vreme o tendință ciudată să facem totul în Next.js, inclusiv API-uri grele sau joburi de fundal. E o greșeală care te va costa scump la facturarea pe serverless sau la performanța pe un VPS mic. Hai să vedem când e cazul să tragi linia și să scrii un server de Node curat.
Monolitul Next.js și iluzia că "le face pe toate"
Next.js e genial pentru ce a fost gândit: SSR, BFF, pagini dinamice și API-uri simple de care are nevoie frontend-ul ca să randeze rapid. Dar când începi să pui în API routes logică complexă de procesare de imagini, importuri masive de date sau conexiuni persistente, începe durerea.
Am avut acum un an un proiect cu vreo 15.000 de utilizatori activi unde echipa inițială scrisese un parser de PDF-uri direct într-o rută de Next.js, rulat pe Vercel. Pe lângă faptul că primeam timeout-uri la greu din cauza limitei de zece secunde pe serverless, costurile serverless crescuseră la 400$ pe lună absolut degeaba.
Cazul 1: Job Processors și Task-uri de lungă durată
Dacă ai nevoie de cozi de mesaje (BullMQ, de exemplu) sau procese cron care rulează mai mult de câteva secunde, Next.js e cea mai proastă alegere. Node.js simplu, rulat cu PM2 pe un VPS de 10 euro, este de zece ori mai stabil.
De ce? Pentru că ai control total asupra memoriei și procesul nu moare după fiecare request. În plus, PM2 se ocupă de clustering și restart-uri automate dacă ceva chiar crapă.
Într-un proiect recent, am mutat procesarea de email-uri și rapoarte dintr-un Next.js API într-un microserviciu Express simplu administrat de PM2. Am economisit 45% la timpul de execuție și n-am mai avut crash-uri de memorie. Next.js trimite doar un webhook scurt către acest microserviciu, iar backend-ul își vede de treabă asincron.
Cazul 2: Microservicii și API-uri interne de mare viteză
Dacă serviciul tău doar primește date de la alte microservicii, le validează și le scrie în baza de date, nu ai nevoie de tot overhead-ul de routing și webpack din Next.js.
Un server Fastify sau Express curat pornește instant, consumă 30-50MB de RAM (față de 150-200MB la Next.js în producție) și duce de 3 ori mai multe request-uri pe secundă pe același hardware.
Trade-off-ul sincer: Trebuie să-ți configurezi singur CORS-ul, rutele, conexiunea la bază și deployment-ul. Nu ai acel "zero config" cu care te-ai obișnuit în Next.js. Dar pe un backend pur, asta e de fapt un avantaj, nu un dezavantaj. Ai control total asupra pipeline-ului de request-uri și poți folosi middleware-uri native fără hack-uri.
Concluzia mea e simplă: folosește Next.js ca pe un BFF excelent pentru interfață. Dar când ai de-a face cu procesare grea de date, microservicii izolate sau job-uri asincrone, un server Node simplu, monitorizat cu PM2, rămâne sfânt.
Voi cum faceți separarea asta în producție? Încă împingeți totul în /pages/api sau /app/api?