import Fastify from 'fastify';
const fastify = Fastify({ logger: true });
// Conexiune persistentă la baza de date, inițializată o singură dată la pornire
fastify.register(async (instance) => {
// db connection logic
});
fastify.post('/api/import', async (request, reply) => {
// Spre deosebire de Next.js, aici conexiunea nu e întreruptă forțat după 15-30 secunde
// Putem rula un job lung sau să trimitem sarcina către un worker cu BullMQ
return { status: 'queued', message: 'Importul a început în fundal.' };
});
const start = async () => {
try {
await fastify.listen({ port: 3000, host: '0.0.0.0' });
} catch (err) {
fastify.log.error(err);
process.exit(1);
}
};
start();Am văzut o tendință ciudată în ultima vreme pe grupurile de dev: lumea pune Next.js peste tot, inclusiv pentru chestii care n-au nicio legătură cu frontend-ul. Am văzut API-uri interne, microservicii de procesat imagini și chiar job-uri de tip cron rulate în interiorul rutelor de API din Next. E o idee proastă și am pățit-o pe pielea mea.
Next.js e o sculă formidabilă pentru ce a fost gândită, dar nu este un înlocuitor universal de backend. Când încerci să-l folosești ca motor principal pentru procesări grele, dai de zid rapid.
Punctul de cotitură: importul a 12.000 de produse
Anul trecut am preluat un proiect unde echipa anterioară scrisese totul în API routes din Next.js, rulat pe Vercel. Printre altele, aveau un script care importa și procesa un XML uriaș cu vreo 12.000 de produse de la un distribuitor.
Rezultatul? Timeout-uri peste timeout-uri la serverless functions, costuri uriașe pe Vercel și zero control pe memoria RAM. Când ai un payload de 50MB de parsat și mapat, serverless-ul te lasă în drum pentru că depășești limitele de timp și memorie.
Am mutat tot acel parser într-un container Docker separat, rulând un server simplu de Fastify pe o instanță de VPS de 10 dolari. Timpul de procesare a scăzut cu 45% pentru că am putut face streaming direct pe disc fără să fim limitați de arhitectura serverless, iar costurile de hosting pentru acea parte au scăzut dramatic. Plus că am scăpat de stresul că moare request-ul la secunda 30.
Unde strălucește Next.js și unde devine un chin
Next.js e genial ca BFF (Backend-for-Frontend). Dacă ai nevoie de server-side rendering, sesiune rapidă pe cookie-uri și rute API simple care doar pasează datele din baza de date către UI, Next e rege.
Dar dacă ai în plan chestii din lista de mai jos, Next.js te va încurca:
- Conexiuni persistente: WebSockets sau Server-Sent Events (SSE). Serverless-ul din Next.js nu e făcut să țină conexiuni deschise minute în șir.
- Background workers sau cozi de mesaje: Dacă vrei să folosești BullMQ pentru a procesa task-uri în fundal, ai nevoie de un proces Node care rulează continuu.
- Sarcini mari consumatoare de CPU: Procesare video, generare de PDF-uri mari sau parsare de fișiere.
De ce se întâmplă asta? Pentru că arhitectura modernă de deployment pentru Next.js este gândită să fie efemeră. Serverul pornește, își face treaba în câteva milisecunde și moare. Încearcă să rulezi un setInterval în Next.js pe Vercel și o să vezi că ori nu rulează deloc, ori îți mănâncă tot bugetul.
Alternativa: Un server Node.js dedicat
Nu ai nevoie de un framework mamut. Un Node.js simplu cu Fastify (sau chiar Express, dacă performanța brută nu e critică) îți oferă control total. Poți să conectezi un client de Redis care stă deschis tot timpul, nu să reinițializezi conexiunea la fiecare request cum ești obligat în serverless.
Trade-off-ul e cel clasic: Next.js îți dă viteză uriașă de dezvoltare pentru UI și integrare rapidă. Un server Node dedicat îți cere să configurezi tu Docker-ul, deployment-ul și monitorizarea, dar îți oferă predictibilitate și performanță stabilă la costuri fixe.
Voi ce folosiți când aveți de scris un microserviciu de backend? Mergeți tot pe Next.js din comoditate sau spargeți aplicația din prima zi?