Next.js este alegerea mea implicită pentru produse web, nu pentru că ar fi la modă. O singură bază de cod TypeScript acoperă ceea ce înainte însemna trei proiecte: site-ul de marketing care trebuie să apară în căutări, aplicația din spatele autentificării și stratul API subțire dintre ele. Acest site este un exemplu mic: rute localizate, metadate generate, sitemap, imagini Open Graph și o rută llms.txt, toate în același proiect App Router.
Încep cu serverul. Paginile și layout-urile sunt Server Components în mod implicit: preiau datele aproape de baza de date, trimit HTML în locul unui bundle JavaScript și păstrează secretele pe server. Folosesc „use client” doar la frunzele arborelui care au nevoie de stare, efecte sau API-uri de browser — un formular, un meniu dropdown, o hartă. Când întregul arbore începe cu „use client”, de regulă urmează un bundle greu și o categorie întreagă de erori.
Alegerea modului de randare ține de produs, nu e o preferință tehnică. Generarea statică e potrivită paginilor care se schimbă la deploy. ISR sau revalidarea pe bază de tag-uri se potrivesc cataloagelor, listărilor și blogurilor care se schimbă în timpul zilei: revalidateTag după o scriere, nu un cronometru pe care nu-l înțelege nimeni. Randarea dinamică cu streaming Suspense e pentru dashboarduri și conținut personal: scheletul apare imediat, iar datele lente vin apoi. Notez pentru fiecare rută de ce este statică sau dinamică; rândul acela scutește o săptămână de întrebări precum „de ce e prețul vechi?”.
Pentru mutații folosesc Server Actions la formularele care aparțin paginii și Route Handlers când ceva din afara aplicației trebuie să o apeleze: webhook de la un procesator de plăți sau Telegram, un client mobil ori o sarcină cron. În ambele cazuri Zod validează datele de intrare pe server, autentificarea se verifică tot acolo, iar clientul nu decide nimic despre bani sau permisiuni. În produsele mari, Next.js rămâne frontend și BFF, în timp ce domeniul principal trăiește într-un serviciu NestJS sau Node.js cu propria bază de date.
Performanța și SEO fac parte din criteriile de finalizare. Folosesc next/image cu dimensiuni reale, next/font pentru a elimina deplasările de layout, generateMetadata și date structurate pe fiecare pagină publică, importuri dinamice pentru widgeturile grele și verific Core Web Vitals pe un telefon de nivel mediu, nu pe MacBook. Deploy-ul este pe Vercel dacă echipa vrea să evite operațiunile, sau un build standalone în Docker pe AWS ori VPS când contează costul, rezidența datelor sau sarcinile lungi.
Refuz „use client” în layout-ul rădăcină, preluarea acelorași date în cinci componente fără să mă gândesc la cache, logica de business ascunsă în middleware și un upgrade major făcut vinerea fără să citesc codemod-urile. Dacă aplicația ta Next.js pare lentă sau fragilă, trimite-mi depozitul și cele mai lente două pagini. Îți spun ce aș muta pe server, ce aș pune în cache și ce aș elimina.
Oferă-i următorului produs cuiva care rămâne.
Ești gata să începem? Trimite-mi un mesaj - pot începe acum și pot rămâne alături de produs. Colaborări pe termen lung, nu o predare în două săptămâni. Să discutăm proiectul, cerințele și cea mai bună cale de urmat.