Salutare tuturor. Acum trei luni am bătut palma cu o agenție de marketing locală ca să le fac un dashboard intern, fiindcă spreadsheet-urile lor cu bugete și performanțe deveniseră complet de necontrolat. Am ales clasicul Next.js (App Router), Prisma și NextAuth, sperând la o dezvoltare rapidă și curată, iar azi vreau să vă povestesc ce a funcționat și unde s-a lăsat cu nopți pierdute.
De la ce am plecat
Agenția are în jur de 45 de angajați, dar dashboard-ul este folosit intens de vreo 20 de media buyeri care gestionează bugete de mii de euro zilnic. Problema lor principală? Pierdeau zilnic câte două ore de om doar ca să adune manual datele din Facebook Ads, Google Ads și TikTok Ads într-un Excel uriaș pentru clienți.
Am vrut să le automatizez fluxul de raportare, să le ofer un sistem de task management intern conectat la campanii și un modul de pontaj. Am estimat proiectul la 3 luni de muncă de unul singur, lucrând în regim de freelancing.
Stack-ul ales și de ce m-am păcălit singur
Pentru că trebuia să livrez repede, am mers pe un stack pe care îl stăpâneam bine: Next.js 14, Prisma ORM cu PostgreSQL (găzduit pe Supabase) și NextAuth pentru autentificare securizată cu Google Workspace-ul lor.
La început, totul a fost ca în povești. NextAuth s-a configurat în mai puțin de o zi. Am pus o restricție simplă pe domeniul de email al agenției și gata, aveam autentificare securizată fără să-mi bat capul cu tabele de parole și fluxuri de resetare. Prisma mi-a permis să generez schemele rapid și să fac migrațiile fără stres. Am economisit lejer 30% din timpul de setup inițial.
Dar apoi a venit momentul integrării datelor de marketing.
Trade-off-ul dureros: Prisma pentru analytics
Aici a fost marea mea greșeală de arhitectură. Prisma este excelentă pentru operațiuni CRUD simple, dar când a trebuit să generez rapoarte agregate pe sute de mii de rânduri de ad-sets descărcate prin cron-uri nocturne, totul a început să meargă extrem de lent.
Query-urile scrise prin Prisma Client generau niște SQL-uri gigantice cu zeci de JOIN-uri inutile. Am avut pagini de raportare care se încărcau în 9-10 secunde, un timp absolut inacceptabil chiar și pentru o aplicație internă.
Soluția a fost dureroasă, dar necesară: am lăsat Prisma doar pentru user management și configurări simple, iar pentru rapoartele grele de analytics am trecut pe raw SQL (prisma.$queryRaw). Diferența a fost colosală. Am coborât timpul de încărcare de la 9 secunde la sub 350ms per request.
Problema cu serverless și conexiunile la DB
Aplicația am urcat-o pe Vercel pe planul Pro de 20$/lună. Totul a funcționat perfect până când baza de date a început să refuze conexiunile dimineața la ora 9:00, când toți userii intrau pe platformă.
Fiecare funcție serverless din Next.js deschidea o nouă conexiune la baza de date prin Prisma, iar limita de conexiuni de pe Supabase era rapid atinsă. Am rezolvat problema doar după ce am configurat corect Supabase Connection Pooler (PgBouncer) și am modificat string-ul de conexiune din Prisma ca să folosească portul corect de pooling.
Ce am învățat din asta?
Am predat proiectul la timp, iar agenția raportează acum o economie de peste 40 de ore de muncă manuală pe săptămână. Totuși, dacă ar fi să o iau de la capăt, n-aș mai folosi Prisma pentru o aplicație orientată pe date masive și analytics. Aș merge direct pe un query builder mai light, cum este Drizzle, sau chiar direct pe query-uri SQL native combinate cu un cache agresiv pe Redis.
Voi cum gestionați conexiunile la baza de date în proiectele Next.js serverless când aveți spike-uri de trafic?