const fastify = require('fastify')({ logger: true });
const Queue = require('bull');
const reportQueue = new Queue('pdf-generation');
// API extrem de rapid, fără overhead-ul de rendering din Next.js
fastify.post('/api/export-pdf', async (request, reply) => {
const { userId, reportData } = request.body;
// În Next.js serverless, un fundal de tipul "fire-and-forget" poate fi omorât instant.
// Aici îl trimitem în siguranță în coada Redis.
await reportQueue.add({ userId, reportData });
return { status: 'queued', message: 'Generarea PDF-ului a început.' };
});
fastify.listen({ port: 3001 }, (err) => {
if (err) throw err;
});Next.js este excelent pentru frontend și BFF (Backend-for-Frontend), dar am văzut prea des echipe care își bagă tot backend-ul în Route Handlers și apoi se miră de ce crapă serverul sau de ce plătesc mii de euro pe Vercel. Dacă ai de făcut procesare grea de date, microservicii sau conexiuni persistente, un server Node chior te scapă de dureri de cap și costuri inutile. Hai să vedem unde tragem linia între Next.js și un backend dedicat.
Coșmarul proceselor lungi în serverless
Am avut un proiect acum un an, un SaaS micuț unde utilizatorii puteau exporta rapoarte PDF masive. Inițial, echipa a zis: „lasă că facem un endpoint în Next, e simplu și avem totul într-un singur loc”. La vreo 8k utilizatori activi, când au început mai mulți inși să dea export simultan, s-a terminat șmecheria.
Vercel ne tăia execuția după 15 secunde din cauza timeout-ului de serverless. Local, serverul de dev mânca 1.5GB RAM de zici că minam criptomonede. Next.js nu este gândit pentru joburi de lungă durată. Serverless-ul vrea funcții rapide și efemere.
Dacă ai de procesat imagini, generat PDF-uri sau sincronizat date mari cu un CRM, mută totul într-un server de Node separat. Noi am făcut un microserviciu Express legat la o coadă BullMQ și am redus consumul de RAM pe serverul principal cu 70%.
Când ai nevoie de WebSockets reale
Next.js pe serverless și WebSockets sunt ca uleiul și apa. Pur și simplu nu se amestecă. Da, poți să folosești servicii externe scumpe ca Pusher sau Supabase Realtime, dar dacă vrei să controlezi tu costurile, ai nevoie de o conexiune persistentă directă.
Un server Node simplu cu Fastify sau Express și biblioteca ws rulat pe un VPS de 10 dolari poate ține mii de conexiuni deschise cu resurse minime. Trade-off-ul e că trebuie să te ocupi singur de deployment, monitorizare și scalare, dar măcar nu ești limitat de arhitectura serverless.
API-uri interne și performanță pură
Dacă API-ul tău e consumat și de o aplicație de mobil, și de alte servicii interne, Next.js adaugă un overhead inutil. Next rutează request-urile prin propriul motor de rendering și routing, ceea ce adaugă milisecunde bune la fiecare apel.
La un proiect cu API intern scris în Fastify, am obținut timpi de răspuns de sub 5ms pentru rutele simple. În Next.js, sub 30ms rar vedeam din cauza middleware-urilor și a abstractizărilor din spate. În plus, dacă ai nevoie de gRPC sau comunicare directă prin RabbitMQ, Next mai mult te încurcă.
Next.js își merită banii când ai nevoie de SEO, server-side rendering și un BFF rapid. Dar când vine vorba de procesare grea și API-uri robuste, un server de Node curat câștigă de fiecare dată. Voi cum faceți? Încă puneți tot backend-ul în Next.js sau ați început să le separați?