Am închis recent un proiect de trei luni pentru o agenție de marketing destul de mare de la noi. Oamenii operau cu vreo 15 surse de date diferite și pierdeau zeci de ore lunar doar mutând cifre dintr-un tab în altul. Planul a fost simplu pe hârtie: un dashboard intern care să tragă tot prin API-uri și să le scuipe într-o interfață curată. Am mers pe stack-ul meu preferat de viteză: Next.js (App Router), Prisma și NextAuth.
După 90 de zile de dev, m-am ales cu câteva învățături pe care mi-ar fi plăcut să le știu în prima săptămână.
NextAuth e un cuțit cu două tăișuri
Pentru login social și chestii basic, NextAuth e aur curat. Te rezolvă în 10 minute. Problema apare când vrei logică de business serioasă în sesiune. Clientul a vrut un sistem de permisiuni pe trei niveluri (Admin, Manager, Client) și, colac peste pupăză, am avut nevoie să stocăm refresh tokens pentru integrările cu Google Ads direct în sesiune ca să nu interogăm baza de date la fiecare request de API extern.
Am pierdut vreo 3 zile bătându-mă cu tipurile de date din TypeScript pentru Session și User. Dacă nu ești atent cum extinzi interfețele alea, te trezești cu erori de tipare care nu spun nimic. E mișto că e „safe”, dar documentația lor pentru cazuri complexe e cam subțire. Sincer, la următorul proiect de genul ăsta, s-ar putea să arunc un ochi pe Lucia Auth sau chiar să fac ceva custom dacă am nevoie de control total pe session management.
Prisma și limitele ORM-ului
Prisma e excelent pentru DX (Developer Experience). Să ai tipare generate automat pentru toată baza de date e un lux care îți salvează enorm de mult timp la început. Am definit vreo 12 tabele și totul mergea brici. Totuși, când a venit momentul să fac rapoartele de performanță — unde trebuia să calculez medii ponderate, CTR și CPC pe mii de rânduri de date istorice — Prisma s-a cam poticnit.
Am încercat să fac agregările prin metodele lor native, dar codul devenise un coșmar de citit și performanța era slabă. Am terminat prin a scrie prisma.$queryRaw pentru vreo 4 query-uri critice. Un JOIN și un GROUP BY bine scrise în SQL curat au bătut la fund orice abstractizare. Am economisit cam 30% din timpul de scriere a codului pe partea de CRUD, dar am plătit cu performanța pe câteva pagini care încărcau în 2 secunde până să trec pe raw SQL. Acum totul zboară sub 200ms.
UI-ul și viteza de livrare
Nu am vrut să pierd timpul cu CSS custom pentru butoane și tabele. Am folosit Shadcn/ui și Tremor pentru grafice. E prima dată când folosesc Tremor într-un proiect real și mi se pare „cheat code” pentru dashboard-uri de business. Arată profesional din prima, fără să pierzi nopțile cu setări de Recharts sau D3.
Rezultatul? Am redus timpul de generare a rapoartelor lunare cu aproximativ 40%. Ce înainte dura o zi întreagă de muncă manuală pentru un account manager, acum se întâmplă în 10 minute cu un export de PDF.
Trade-off-ul a fost clar: am ales viteză de livrare în detrimentul unei arhitecturi puriste. Am lăsat multă logică de business direct în Server Components, ceea ce face testarea unitară mai dificilă, dar pentru un tool intern care trebuia să fie gata ieri, a fost decizia corectă.
Voi ce folosiți pentru dashboard-uri interne unde clientul vrea „totul acum” dar datele sunt un haos total?