eduardweb.
Prezentări & ShowcaseIntermediar#nextjs#prisma#web-dev#showcase#nextauth

Dashboard intern pentru o agenție de marketing: 3 luni de dev cu Next.js, Prisma și NextAuth

De Paul Ene, 20 iul. 2026 · 11 vizualizări · 3 like-uri

Postat 20 iul. 2026

Am terminat recent de livrat un dashboard intern pentru o agenție de marketing locală care se lăbărțase în vreo 15 Google Sheets și tool-uri împrăștiate. Am mers pe stack-ul clasic de azi: Next.js (App Router), Prisma și NextAuth. Vreau să vă povestesc rapid cum a fost experiența asta de 3 luni, ce a mers super și unde ne-am luat blockere de ne-am zgâriat pe ochi.

Cerințele și de unde am plecat

Agenția are în jur de 40 de oameni și vreo 120 de clienți activi. Aveau nevoie să vadă într-un singur loc bugetele de ad-uri (Facebook, Google, TikTok), statusul task-urilor din Asana și niște rapoarte financiare simple. Nimic de nuanță științifică, dar volumul de date era destul de mare și împrăștiat peste tot.

Am avut la dispoziție fix 3 luni pentru versiunea 1.0, lucrând singur pe partea de dev, plus un designer part-time care îmi dădea layout-urile în Figma.

Ce a mers ceas: Prisma și NextAuth

Prisma e pur și simplu aur curat pentru viteză. Am avut vreo 18 tabele în PostgreSQL. Schema s-a modificat de zeci de ori în primele săptămâni, pe măsură ce descopeream cum livrează API-urile de la Meta datele de tracking. Cu prisma db push în dev și migrațiile automate în staging, am economisit cel puțin 30% din timpul pe care l-am fi pierdut scriind SQL manual sau bătându-ne cu migrații rigide.

NextAuth (acum Auth.js) ne-a rezolvat login-ul cu Google Workspace în fix o după-amiază. Agenția folosește Google pentru tot, așa că providerul de Google OAuth a fost un no-brainer. Am pus și un mic middleware care să verifice dacă domeniul de email este cel al agenției și gata, am avut securitate de bază fără bătăi de cap.

Unde ne-am lovit cu capul de prag: Next.js App Router

Aici vine trade-off-ul sincer. App Router-ul e promovat ca fiind răspunsul la toate problemele omenirii, dar când ai dashboard-uri complexe, cu tabele interactive și grafice dinamice, Server Components devin un coșmar de gestionat.

Am început prin a face fetch la date pe server. Totul părea curat. Dar când managerii au început să ceară filtre peste filtre (să poată filtra simultan după 5 parametri: interval de timp, client, platformă, status campanie și manager), trimiterea stării înapoi la server prin URL query params a transformat logica într-un haos greu de debuguit.

Până la urmă, am luat o decizie pragmatică: am mutat ecranele de raportare cele mai complexe pe Client Components ("use client") și am făcut fetch clasic prin API Routes, folosind SWR pentru caching. Da, am pierdut beneficiul randării pe server, dar am câștigat la fluiditatea interfeței și am salvat vreo două săptămâni de codat workaround-uri ciudate. Nu totul trebuie să fie Server Component doar pentru că așa e trendul.

Performanța la final

La sfârșitul celor 3 luni, dashboard-ul încarcă datele agregate în sub 1.2 secunde, față de cele 10-15 secunde cât dura să se deschidă un spreadsheet mamut cu scripturi custom. Am redus timpul săptămânal de raportare al echipei de la 6 ore per manager la doar 30 de minute.

Pentru genul ăsta de aplicații B2B interne, Next.js e încă o alegere solidă, dar trebuie să știi când să renunți la Server Components în favoarea unui SPA clasic montat în interiorul framework-ului.

Voi cum abordați dashboard-urile complexe în Next.js? Rămâneți pe SSR pur sau capitulați repede la client-side fetch când filtrele devin prea stufoase?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

Doar membrii comunității pot lăsa comentarii.