import Fastify from 'fastify';
import { Queue } from 'bullmq';
const fastify = Fastify({ logger: true });
const reportQueue = new Queue('reports', {
connection: { host: '127.0.0.1', port: 6379 }
});
// Endpoint ultra-rapid pentru webhook-uri
fastify.post('/webhook/stripe', async (request, reply) => {
const event = request.body;
// În loc să procesăm totul pe loc, trimitem direct în coada de Redis
await reportQueue.add('process-payment', { event }, {
attempts: 3,
backoff: 1000
});
// Răspundem Stripe-ului în sub 20ms
return reply.code(200).send({ received: true });
});
fastify.listen({ port: 4000, host: '0.0.0.0' }, (err) => {
if (err) throw err;
});Am văzut în ultimii ani o tendință ciudată: echipă după echipă trântește totul în Next.js, de la frontend la webhook-uri, procesare de imagini și crons. Next e genial pentru SSR și site-uri orientate spre SEO, dar când încerci să-l folosești pe post de briceag elvețian pentru tot backend-ul, te lovești repede de zid.
Unde se rupe filmul cu Next.js pe backend
Anul trecut am lucrat la o aplicație cu vreo 15k utilizatori activi zilnic. Echipa inițială pusese totul în Next.js (API routes + Server Actions). Totul frumos la început, până când am început să primim webhook-uri de la Stripe și un furnizor de telecomunicații.
Next.js (mai ales când e deployed pe Vercel sau alte medii serverless) rulează într-un mediu scurt-trăit (ephemeral). Fiecare request creează sau reutilizează scurt o instanță. Când webhook-ul trebuia să genereze un PDF și să trimită 3 email-uri, prindeam frecvent timeout-ul de 10-15 secunde. Costurile pe Vercel au sărit cu 40% într-o singură lună doar din cauza memoriei consumate de rutele de API care încărcau tot bundle-ul de React în fundal.
Când am scos procesarea de PDF-uri și webhook-urile într-un microserviciu separat în Fastify pe un VPS de 10$, timpii de răspuns au scăzut de la 1.2 secunde la 45ms.
Scenarii clare unde un server Node separat bate Next.js
-
Job Processors și cozi (BullMQ, RabbitMQ) Dacă ai procese async — encodare video, generare de rapoarte, parsare de fișiere mari —, un API route din Next.js e o alegere neinspirată. Ai nevoie de un proces Node care stă mereu pornit, ascultă într-o coadă de Redis și își gestionează memoria fără să fie omorât de un timeout impus.
-
Conexiuni persistente (WebSockets, gRPC, Server-Sent Events) Next.js nu e gândit nativ pentru conexiuni de lungă durată. Dacă construiești un chat în timp real sau un dashboard cu metrici live, un server Node simplu cu
wssau Socket.io pus în spatele PM2 rezolvă problema fără hack-uri urâte. -
API-uri interne cu latență mică Dacă ai microservicii care vorbesc între ele în rețeaua internă, middleware-ul și routing-ul din Next adaugă overhead. Un server Node minimalist răspunde în câteva milisecunde și folosește sub 50MB RAM.
Trade-off-uri: ce pierzi când alegi Node separat
Nu zic să abandonezi Next.js peste tot. Dacă ai doar CRUD-uri simple pentru frontend, rutele de API din Next sunt perfecte și te scapă de mentenanță.
Dacă scrii un server Node propriu:
- Zero setup gratuit: Trebuie să-ți configurezi singur Docker, PM2 sau Docker Compose, plus reverse proxy (Nginx sau Caddy).
- Tipuri duplicate: Dacă nu folosești un monorepo (Turborepo sau Nx) cu pachete partajate, vei copia interfețele de TypeScript între backend și frontend până te plictisești.
- CI/CD separat: Deploy-ul nu mai e un simplu
git pushpe Vercel. Trebuie să configurezi GitHub Actions, build-uri de Docker și zero-downtime reloads.
Scurt și la obiect: folosește Next.js pentru ce e el bun — UI, SSR și un BFF (Backend For Frontend) subțire. Când ai heavy lifting, joburi asincrone sau conexiuni de lungă durată, scoate backend-ul într-un serviciu Node dedicat.
Voi cum gestionați cozile de fundal în proiectele cu Next? Le treceți în servicii separate sau le împingeți în serverless functions cu servicii externe gen QStash sau Inngest?