Laravel impune o ierarhie de directoare familiară echipei, dar familiaritatea nu înseamnă automat claritate. Firul de discuție clarifică rolul fiecărei zone a scheletului și unde apar greșelile tipice când proiectul crește dincolo de tutorial. Scopul nu e memorarea unui arbore de foldere, ci înțelegerea fluxului requestului și a locului unde adaugi cod nou fără a sparge convențiile frameworkului.
Fiecare request intră prin `public/index.php`, încarcă autoloaderul și instanțiază aplicația. Kernel-ul HTTP aplică middleware global, apoi pe grupuri (`web`, `api`), apoi pe rută. Înțelegerea ordinii middleware explică de ce CSRF, sesiunea sau throttling apar sau dispar pe anumite endpoint-uri. Providerii înregistrează binding-uri și evenimente la boot; ține boot-ul ușor — operații grele acolo încetinesc fiecare request sau fiecare comandă Artisan. Când adaugi middleware custom, decide explicit dacă aparține grupului web sau api; amestecul greșit produce simptome greu de reprodus, de exemplu sesiune pornită pe rute JSON.
Gruparea rutelor pe fișiere (`web.php`, `api.php`) reduce zgomotul. Folosește `name()` pentru rutele referite din Blade sau din mail-uri, ca refactorul URL-urilor să nu rupă link-uri. Parametrii de rută pot fi constrânși cu regex sau cu model binding; binding-ul implicit presupune convenții de nume — când le încalci, primești 404 inexplicabil până verifici cheia din rută versus coloana din model. Prefixele de nume (`forum.`) evită coliziuni când aplicația crește; `route()` devine lizibil dacă numele descriu intenția, nu doar path-ul literal.
Valorile din `.env` sunt citite în fișierele din `config/`; codul aplicației ar trebui să apeleze `config("mail.default")`, nu `env()` direct în clase random, pentru că config cache în producție ignoră `.env` la runtime. Documentează cheile obligatorii pentru un mediu nou într-un exemplu `.env.example` fără secrete reale. Diferențele între local, staging și producție se rezolvă prin env, nu prin branch-uri de cod divergente. După schimbarea `.env` pe server, pașii `config:clear` sau redeploy cu cache regenerat previn situația în care codul citește valori vechi înghețate în fișierul compilat.
Blade rămâne server-rendered; asset-urile pot fi gestionate cu Vite sau cu un pipeline anterior, important e să nu amesteci URL-uri hardcodate către fișiere care nu există pe serverul de deploy. `@vite` sau directive echivalente leagă manifestul de build de template. Pentru forum sau CMS, separă layout-ul principal de partial-urile reutilizabile (navigare, alerte, paginare) ca să nu copiezi HTML între pagini. Rulează build-ul de frontend în pipeline-ul de deploy, nu manual pe laptop, astfel încât hash-urile din manifest să corespundă fișierelor de pe disk la fiecare release.
Bootstrap și ciclul de viață al requestului
Fiecare request intră prin `public/index.php`, încarcă autoloaderul și instanțiază aplicația. Kernel-ul HTTP aplică middleware global, apoi pe grupuri (`web`, `api`), apoi pe rută. Înțelegerea ordinii middleware explică de ce CSRF, sesiunea sau throttling apar sau dispar pe anumite endpoint-uri. Providerii înregistrează binding-uri și evenimente la boot; ține boot-ul ușor — operații grele acolo încetinesc fiecare request sau fiecare comandă Artisan. Când adaugi middleware custom, decide explicit dacă aparține grupului web sau api; amestecul greșit produce simptome greu de reprodus, de exemplu sesiune pornită pe rute JSON.
Rute declarative și nume stabile
Gruparea rutelor pe fișiere (`web.php`, `api.php`) reduce zgomotul. Folosește `name()` pentru rutele referite din Blade sau din mail-uri, ca refactorul URL-urilor să nu rupă link-uri. Parametrii de rută pot fi constrânși cu regex sau cu model binding; binding-ul implicit presupune convenții de nume — când le încalci, primești 404 inexplicabil până verifici cheia din rută versus coloana din model. Prefixele de nume (`forum.`) evită coliziuni când aplicația crește; `route()` devine lizibil dacă numele descriu intenția, nu doar path-ul literal.
Config versus .env
Valorile din `.env` sunt citite în fișierele din `config/`; codul aplicației ar trebui să apeleze `config("mail.default")`, nu `env()` direct în clase random, pentru că config cache în producție ignoră `.env` la runtime. Documentează cheile obligatorii pentru un mediu nou într-un exemplu `.env.example` fără secrete reale. Diferențele între local, staging și producție se rezolvă prin env, nu prin branch-uri de cod divergente. După schimbarea `.env` pe server, pașii `config:clear` sau redeploy cu cache regenerat previn situația în care codul citește valori vechi înghețate în fișierul compilat.
Resurse frontend în același repo
Blade rămâne server-rendered; asset-urile pot fi gestionate cu Vite sau cu un pipeline anterior, important e să nu amesteci URL-uri hardcodate către fișiere care nu există pe serverul de deploy. `@vite` sau directive echivalente leagă manifestul de build de template. Pentru forum sau CMS, separă layout-ul principal de partial-urile reutilizabile (navigare, alerte, paginare) ca să nu copiezi HTML între pagini. Rulează build-ul de frontend în pipeline-ul de deploy, nu manual pe laptop, astfel încât hash-urile din manifest să corespundă fișierelor de pe disk la fiecare release.