Ciclo di vita della richiesta (Request Lifecycle)

Introduzione

Quando si utilizza uno strumento nel “mondo reale”, ci si sente più sicuri se si comprende come funziona quel determinato strumento. Lo sviluppo di applicazioni non fa eccezione. Quando si comprende il funzionamento degli strumenti di sviluppo, ci si sente più a proprio agio e sicuri nell’utilizzarli.

Lo scopo di questo documento è fornire una panoramica generale del funzionamento del framework Laravel. Conoscendo meglio l’intero framework, tutto sembra meno “magico” e si sarà più sicuri nella creazione delle applicazioni. Se non si comprendono subito tutti i termini, non scoraggiatevi! Cercate di capire almeno le basi di ciò che sta accadendo e la vostra conoscenza crescerà man mano che esplorerete altre sezioni della documentazione.

Panoramica del Ciclo di Vita

Primo step

Il punto di ingresso per tutte le richieste ad un’applicazione Laravel è il file public/index.php. Tutte le richieste vengono indirizzate a questo file tramite la configurazione del tuo server web (Apache / Nginx). Il file index.php non contiene molti codici. Piuttosto, è un punto di partenza per caricare il resto del framework.

Il file index.php carica la definizione dell’autoloader generato da Composer e quindi recupera un’istanza dell’applicazione Laravel da bootstrap/app.php. La prima azione intrapresa da Laravel stessa è creare un’istanza dell’applicazione / container di servizi.

HTTP / Console Kernels

Successivamente, la richiesta in ingresso viene inviata al kernel HTTP o al kernel della console, a seconda del tipo di richiesta che sta entrando nell’applicazione. Questi due kernel fungono da punto centrale attraverso il quale tutte le richieste passano. Per ora, concentriamoci sul kernel HTTP, che si trova in app/Http/Kernel.php.

Il kernel HTTP estende la classe Illuminate\Foundation\Http\Kernel, che definisce un array di bootstrappers che verranno eseguiti prima che la richiesta venga eseguita. Questi bootstrap configurano la gestione degli errori, la configurazione del logging, rilevano l’ambiente dell’applicazione e svolgono altre attività che devono essere svolte prima che la richiesta venga effettivamente gestita. Tipicamente, queste classi gestiscono la configurazione interna di Laravel di cui non devi preoccuparti.

Il kernel HTTP definisce anche una lista di middleware HTTP che tutte le richieste devono attraversare prima di essere gestite dall’applicazione. Questi middleware gestiscono la lettura e la scrittura della sessione HTTP, determinano se l’applicazione è in modalità di manutenzione, verificano il token CSRF e altro ancora. Ne parleremo meglio tra poco.

La firma del metodo handle del kernel HTTP è piuttosto semplice: riceve una richiesta (Request) e restituisce una risposta (Response). Pensate al kernel come a una grande scatola nera che rappresenta l’intera applicazione. Alimentatelo con richieste HTTP e restituirà risposte HTTP.

Fornitore di servizi (Service Providers)

Una delle azioni di bootstrap più importanti del kernel è il caricamento dei service provider per l’applicazione. I service provider sono responsabili del bootstrap di tutti i vari componenti del framework, come il database, la coda (queue), la validazione e i componenti di routing. Tutti i service provider dell’applicazione sono configurati nell’array “providers” del file di configurazione config/app.php.

Laravel itererà attraverso questa lista di provider e istanzierà ognuno di essi. Dopo l’istanziazione dei provider, verrà chiamato il metodo “register” su ciascun provider. Successivamente, una volta che tutti i provider sono stati registrati, verrà chiamato il metodo “boot” su ciascun provider. Questo è necessario affinché i service provider possano dipendere da ogni binding del container essere registrato e disponibile al momento dell’esecuzione del loro metodo “boot“.

Essenzialmente, ogni funzionalità principale offerta da Laravel viene bootstrap e configurata da un service provider. Poiché essi bootstrap e configurano così tante funzionalità offerte dal framework, i service provider sono l’aspetto più importante dell’intero processo di bootstrap di Laravel.

Rotte (Routing)

Uno dei service provider più importanti nella tua applicazione è App\Providers\RouteServiceProvider. Questo service provider carica i file di routing contenuti nella directory delle rotte (routes) dell’applicazione. Apri pure il codice di RouteServiceProvider e dai un’occhiata a come funziona!

Una volta che l’applicazione è stata avviata e tutti i service provider sono stati registrati, la richiesta (Request) verrà passata al router per la dispatch. Il router dispatcherà la richiesta verso una route o un controller, eseguendo eventuali middleware specifici della route.

I middleware forniscono un meccanismo conveniente per filtrare o esaminare le richieste HTTP che entrano nella tua applicazione. Ad esempio, Laravel include un middleware che verifica se l’utente dell’applicazione è autenticato. Se l’utente non è autenticato, il middleware reindirizzerà l’utente alla schermata di accesso. Tuttavia, se l’utente è autenticato, il middleware permetterà alla richiesta di procedere nell’applicazione. Alcuni middleware sono assegnati a tutte le route dell’applicazione, come quelli definiti nella proprietà $middleware del tuo kernel HTTP, mentre altri sono assegnati solo a specifiche route o gruppi di route. Puoi saperne di più sui middleware leggendo la documentazione completa sui middleware.

Se la richiesta supera tutti i middleware assegnati alla route corrispondente, verrà eseguito il metodo della route o del controller e la risposta restituita dal metodo della route o del controller verrà inviata attraverso la catena di middleware della route.

Conclusione

Una volta che il metodo della route o del controller restituisce una risposta, la risposta viaggerà all’indietro attraverso i middleware della route, dando all’applicazione la possibilità di modificare o esaminare la risposta in uscita.

Infine, una volta che la risposta viaggia all’indietro attraverso i middleware, il metodo handle del kernel HTTP restituisce l’oggetto di risposta e il file index.php chiama il metodo send sulla risposta restituita. Il metodo send invia il contenuto della risposta al browser web dell’utente. Abbiamo concluso il nostro percorso attraverso l’intero ciclo di vita delle richieste in Laravel!

Concentrarsi sui Service Provider

I provider di servizi sono davvero la chiave per avviare un’applicazione Laravel. Viene creata un’istanza dell’applicazione, vengono registrati i provider di servizi e la richiesta viene passata all’applicazione avviata. È davvero così semplice!

Avere una solida comprensione di come un’applicazione Laravel viene costruita e avviata tramite i provider di servizi è molto prezioso. I provider di servizi predefiniti dell’applicazione sono memorizzati nella directory app/Providers.

Per impostazione predefinita, l’AppServiceProvider è abbastanza vuoto. Questo provider è un ottimo punto per aggiungere l’avvio e le associazioni del tuo container di servizi personalizzati. Per applicazioni di grandi dimensioni, potresti desiderare di creare diversi provider di servizi, ognuno con un avvio più dettagliato per servizi specifici utilizzati dalla tua applicazione.