Am terminat recent un dashboard intern pentru o agenție de marketing cu care colaborez de ceva vreme. Proiectul a durat cam 3 luni, de la primul npx create-next-app până la deploy-ul final în producție. Problema lor era clasică: oamenii pierdeau cam 10 ore pe săptămână mutând date din Google Ads și Facebook Ads în niște Excel-uri obosite ca să facă rapoarte pentru clienți. Am zis că pot să automatizez totul și să le ofer o interfață unde să vadă în timp real ce se întâmplă cu bugetele.
Am mers pe stack-ul meu preferat de acum: Next.js (App Router), Prisma ca ORM și NextAuth pentru autentificare. Pare simplu pe hârtie, dar realitatea din teren m-a lovit destul de repede.
De ce am ales stack-ul ăsta și unde m-am fript
Next.js cu App Router e excelent pentru că poți să faci fetch la date direct în Server Components. Am eliminat complet nevoia de a scrie 50 de endpoint-uri de API separate doar ca să populez niște tabele. Totul e mult mai curat când scrii cod de backend direct în componenta de UI. Totuși, am învățat pe pielea mea că caching-ul în Next.js e o bestie greu de îmblânzit. La început, datele din dashboard rămâneau „agățate” deși în baza de date se schimbau. Am pierdut vreo două zile înțelegând diferența dintre revalidatePath și revalidateTag și cum să nu fac overkill cu ele.
Prisma e un vis pentru developer experience. Sincer, după ce înveți schema lor, nu-ți mai vine să scrii SQL chior. Dar am dat de un trade-off mare: la un moment dat a trebuit să fac niște rapoarte complexe de atribuire, unde aveam nevoie de niște agregări serioase pe vreo 80.000 de rânduri de log-uri. Prisma a început să gâfâie. Am ajuns să scriu prisma.$queryRaw pentru că ORM-ul genera niște query-uri cu prea multe join-uri inutile care îmi urcau timpul de răspuns la 4-5 secunde. Cu SQL scris de mână, am coborât sub 400ms.
Autentificarea și integrarea cu Google
Pentru login, am folosit NextAuth (Auth.js mai nou). Dacă ai nevoie doar de „Login with Google”, e sfânt. Îl configurezi în 20 de minute și ai scăpat de grija stocării parolelor sau a securității sesiunilor. Partea grea a fost când am avut nevoie de access_token-ul de la Google ca să fac request-uri către API-ul lor de Ads în numele userului.
NextAuth nu e neapărat cel mai intuitiv când vrei să persiști token-uri de refresh în baza de date fără să faci hack-uri murdare prin callback-uri. Am sfârșit prin a salva manual token-ul de refresh în profilul de user din baza de date ca să pot face fetch la datele de marketing chiar și când userul nu e logat (pentru job-urile de noapte care sincronizează datele).
Ce am învățat după 3 luni
Am economisit agenției cam 30% din timpul de raportare lunară. Asta e victoria reală. Tehnic vorbind, m-am convins că nu trebuie să te complici cu arhitecturi de microservicii pentru un tool intern. Un monolit în Next.js e mai mult decât suficient dacă știi să-ți organizezi folderele.
Un sfat sincer: nu folosi Server Actions pentru tot ce mișcă. Pentru formulare simple de editat un profil e ok, dar pentru dashboard-uri interactive unde userul tot filtrează și sortează date, un API endpoint clasic combinat cu TanStack Query (React Query) oferă o experiență mult mai fluidă pe client. Am refăcut partea de filtrare după o lună pentru că Server Actions se simțeau „clunky” la fiecare click.
Per total, am reușit să livrez ceva care chiar e folosit zilnic de 15 oameni. Prisma mi-a salvat zeci de ore de debugging pe tipuri de date, iar Next.js mi-a permis să fac deploy rapid pe Vercel fără să mă bat cu Docker-ul de la început.
Voi ce stack folosiți pentru tool-uri interne unde viteza de livrare e mai importantă decât scalabilitatea teoretică?