eduardweb.
Prezentări & ShowcaseIntermediar#nextjs#prisma#postgresql#showcase#nextauth

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

De Maria Vasilescu, 12 iun. 2026 · 20 vizualizări · 2 like-uri

Postat 12 iun. 2026

Salutare! Am terminat recent un dashboard intern pentru o agenție de marketing locală (80+ useri activi, integrări cu Meta și Google Ads) și vreau să vă las aici câteva concluzii sincere după 3 luni de code-mashing. Am mers pe clasicul combo Next.js, Prisma și NextAuth. Sună modern și rapid pe hârtie, dar realitatea din producție ne-a lovit destul de repede în mufă.

De ce am ales stack-ul ăsta și ce a funcționat

Agenția avea nevoie de un agregator. Oamenii voiau să vadă într-un singur ecran campaniile active de pe Facebook, bugetele consumate pe Google Ads și lead-urile venite din diverse formulare proprietare.

Next.js (App Router) a fost o alegere naturală pentru că echipa lor de design dorea animații fluide și un feel de aplicație nativă, nu pagini care se reîncarcă la fiecare click. Prisma ne-a ajutat enorm la început. Autocomplete-ul din editor și migrațiile curate ne-au permis să livrăm primul MVP funcțional în doar 3 săptămâni.

Cât despre autentificare, NextAuth cu Google Provider a fost "plug and play". Agenția folosește Google Workspace, așa că am limitat accesul doar pentru domeniul lor oficial. Am rezolvat securitatea în mai puțin de o zi de muncă, ceea ce la alte proiecte îmi lua lejer o săptămână de configurat JWT-uri și sesiuni manuale.

Partea dureroasă: Conexiunile la baza de date și timeout-urile

Aici a început distracția. Am găzduit baza de date Postgres pe Supabase și aplicația pe Vercel Serverless. La primul test de încărcare mai serios, când 15 oameni din agenție au început să ruleze rapoarte simultan, baza de date a început să dea erori de conexiune. Prisma deschidea o conexiune nouă la fiecare invocare serverless și depășeam imediat limita de 40 de conexiuni concurente ale planului de bază.

Am rezolvat problema adăugând un Supabase Connection Pooler (folosind portul de tranzacții 6543 în loc de cel direct), dar ne-am pierdut o zi întreagă făcând debug pe erori criptice în logurile din Vercel.

O altă palmă peste ochi au fost Server Actions. Sunt excelente pentru chestii simple, cum ar fi schimbarea unui status sau un update de profil. Însă, când am avut de procesat fișiere CSV de 20MB cu date de conversie, Server Actions au dat timeout după 15 secunde (limita standard pe Vercel Pro). Am fost nevoiți să mutăm procesarea grea pe un endpoint de API clasic (/api/upload) și să trimitem progresul prin Server-Sent Events.

Ce am învățat și ce aș face diferit

Am economisit cam 30% din timpul de design folosind shadcn/ui. Componentele sunt direct în codul tău, le poți modifica cum vrei, fără să te bați cu specificitatea CSS din librării monolitice cum era Material UI pe vremuri.

Dacă aș lua proiectul de la zero azi, aș muta toate scripturile de sync (care trag date din Meta API la fiecare oră) pe un VPS separat de 5 dolari pe lună. Să rulezi cron-uri lungi pe serverless e o gaură neagră pentru buget. Vercel e genial pentru frontend și API-uri rapide, dar e groaznic de scump dacă ai procese de fundal care durează minute în șir.

În final, clientul e super mulțumit. Dashboard-ul le salvează cam 4 ore de muncă manuală pe săptămână pentru fiecare account manager.

Voi ce folosiți pentru dashboard-urile interne rapide? Mergeți pe custom dev cu Next.js sau preferați tool-uri low-code gen Retool când designul nu e o prioritate absolută?

Răspunsuri 0

Se încarcă răspunsurile…

Loghează-te pentru a răspunde

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