Come abbiamo già visto nel capitolo precedente, la struttura di default di un progetto Laravel è questa:

.app-prova
├── .editorconfig
├── .env
├── .env.example
├── .gitattributes
├── .gitignore
├── app
├── artisan
├── bootstrap
├── composer.json
├── composer.lock
├── config
├── database
├── lang
├── package.json
├── phpunit.xml
├── public
├── README.md
├── resources
├── routes
├── storage
├── tests
├── vendor
└── vite.config.js

Viene intesa come punto di partenza di qualsiasi progetto, ma siamo liberi di aggiungere tutte le directory che reputiamo necessarie al nostro progetto e aggiungere file PHP in ogni posizione. Per sfruttare i meccanismi di autoloading di composer, il mio consiglio è quindi quello di rispettare la struttura originale ed aggiungere le directory necessarie.

app

La directory che ci interessa maggiormente è quella app, dove scriveremo il codice del nostro progetto. Al suo interno, troveremo le directory Console, Exceptions, Http, Models e Providers. Teniamo presente che molte altre directory verranno create automaticamente dal comando Artisan una volta che aggiungeremo più funzioni/strutture al nostro progetto, ma è in questa directory che lavoreremo maggiormente.

config

Come suggerisce il suo nome, la directory config contiene i file di configurazione, che approfondiremo più avanti in questa guida. Dato che quasi tutti i file presenti di default “dichiarano qualcosa” e non eseguono comandi, una buona idea è quella di dare una rapida occhiata per scoprire i vari setting che possiamo liberamente impostare.

database

Questa directory è fondamentale e, come approfondiremo in seguito, conterrà le Migrations, ovvero i “cambi di struttura” al nostro database, i Seed e altro. È importante capire che l’impostazione di collegamento al database NON viene effettuata qui.

public

La directory public è fondamentale quanto quella app, perché conterrà tutti i file che saranno accessibili pubblicamente dal nostro sito/dominio, come i file CSS e Javascript. Qui inoltre troviamo il file index.php (da non toccare) verso il quale vengono reindirizzate tutte le richieste HTTP del nostro progetto. Sarà lui poi a inizializzare il framework e a “smistare le richieste” tramite le routes, che vedremo fra poco.

resources

Laravel include un template engine, Blade, a cui dedicheremo un capitolo a parte. Per il momento ci serve sapere che nella directory resources i file di questo template, ovvero le view, vengono conservate qui, nella sottodirectory views.

routes

Probabilmente la directory routes è la seconda per importanza dopo app, ed è la prima nella quale lavoreremo in questa guida. Le routes sono appunto le “rotte” del nostro sito: corrispondono alla gestione delle richieste che avvengono quando un utente chiama un URL del nostro progetto. Dovremmo, ad esempio, essere pronti a rispondere alla route /user/1 (ovvero https://nostrodominio.com/user/1) definendola qui. Per farlo, Laravel predispone 4 tipi di routes, che sono intercambiabili fra di loro, in quattro file separati a seconda “dello scopo”: in api.php definiremo le routes per i nostri endpoint API, se il nostro progetto naturalmente ne ha. In web.php saranno definite

La definizione delle route non cambia, “si scrive uguale”, quindi la differenziazione è soltanto logica.

Vedremo più avanti, nei casi specifici, le altre directory, solo nel momento in cui saranno rilevanti ai fini della nostra guida.