import Fastify from 'fastify';
const fastify = Fastify({ logger: true });
// Connection pool stabil, nu se reinițializează la fiecare request
const dbPool = {
query: async (sql: string) => `Rezultat pentru: ${sql}`
};
fastify.get('/api/v1/heavy-work', async (request, reply) => {
const data = await dbPool.query('SELECT * FROM heavy_table');
return { success: true, data };
});
const start = async () => {
try {
await fastify.listen({ port: 3001, host: '0.0.0.0' });
} catch (err) {
fastify.log.error(err);
process.exit(1);
}
};
start();M-am lovit des în ultima vreme de tendința de a arunca Next.js peste orice proiect, doar pentru că e la modă. Hai să vorbim sincer despre momentele în care un server Node.js simplu, scris de mână, bate Next-ul la fundul gol pe performanță și costuri de infrastructură.
Am avut acum un an un caz concret. La un proiect cu vreo 12k utilizatori activi, aveam un serviciu de import rapoarte unde utilizatorii urcau CSV-uri mari. Inițial, echipa îl scrisese ca o rută de API în Next.js. La fișiere de peste 50MB, serverul dădea crash din cauza limitei de memorie, iar pe Vercel ne loveam constant de timeout-ul de 15 secunde. Am mutat toată logica asta pe un microserviciu separat în Node.js simplu, rulat în PM2 pe un VPS de 10 euro. Am rezolvat problema instant și am economisit cam 30% la consumul total de resurse.
Când Next.js devine o piatră de moară
Next.js este un framework excelent pentru frontend, SEO și ce înseamnă Backend-for-Frontend (BFF). Dar când începi să-l folosești pentru API-uri interne grele, devine ineficient.
În primul rând, ai overhead-ul de build. Next.js trebuie să compileze paginile, să facă tree-shaking pentru React și să pregătească rutele de serverless. Dacă ai doar un API intern care vorbește cu o bază de date, de ce să tragi după tine tot runtime-ul de React și webpack?
În al doilea rând, managementul conexiunilor. În Next.js (mai ales pe serverless), rutele de API sunt stateless și se pot închide oricând. Asta înseamnă că o să omori baza de date cu conexiuni noi la fiecare request, în loc să folosești un connection pool stabil, așa cum ai face pe un server Node de sine stătător.
Job Processors și procese de fundal
Dacă ai nevoie de cozi de mesaje (BullMQ, RabbitMQ) sau cron-uri complexe, Next.js pur și simplu nu e făcut pentru asta. Nu poți lăsa un event loop deschis la infinit într-o funcție serverless sau într-o rută care se vrea efemeră.
Pentru un procesator de joburi, ai nevoie de un proces Node care rulează continuu. Noi folosim Fastify cu BullMQ gestionat prin PM2. Consumă în jur de 80MB RAM în idle și procesează mii de joburi pe secundă fără să clipească.
Trade-off-ul sincer
Evident, există și un cost. Dacă alegi un server Node separat, pierzi integrarea nativă din Next.js. Trebuie să îți configurezi singur CORS-ul, securitatea (helmet, rate limiting), deployment-ul (Docker sau PM2) și monitorizarea. Nu mai ai "deploy cu un singur click".
Pentru un MVP rapid, s-ar putea să nu merite efortul de a avea două repo-uri separate. Dar dacă ai trecut de faza de validare și ai procesare grea de date, separarea asta îți va salva mulți bani și nervi.
Voi cum procedați? Puneți totul în Next.js până crapă, sau separați din start backend-ul greu de partea de prezentare?