Laravel

Stéphane Hulard

Consultant, Formateur, Contributeur.

Je commence par me présenter, je suis Stéphane Hulard, ▶ consultant indépendant. J'aime beaucoup travailler sur des projets legacy pour accompagner les équipes à les reprendre en main.
▶ Je suis aussi formateur principalement autour des outils et méthodes liés à la qualité logicielle.
▶ Et enfin contributeur, pas autant que je le voudrais mais les projets open sources me permettent d'élargir ma vision du métier en bénéficiant de l’expertise et du soutien de la communauté ce qui est un atout précieux.
Aujourd'hui je travaille principalement avec Exoskills une entreprise Lyonnaise spécialisée dans l'accompagnement à la transformation digitale de ses clients. Nous sommes d'ailleurs en recherche de profil technique si vous êtes interessés, n'hésitez pas à venir me voir après.

Laravel ?

Un peu d'histoire…

2011: Premier commit,
2013: v4.0.0,
2015: v5.0.0,
2019: v5.9.0 ?

▶ Il existe depuis presque 10 ans mais il s'est créé une place bien au chaud parmis les frameworks les plus populaires depuis la version 5.0, il y a 4 ans.
▶ Cette version apporte d'ailleurs un conteneur d'injection de dépendance avec du contextual binding, un des premiers outils à le proposer. C'est ce qui m'a fait basculer sur Laravel à cette période.
▶ La branche 5.0 est celle qui est active actuellement. Avec un rythme de deux releases mineures par ans, les presques 500 contributeurs du projet sont très actifs.
Il y a même aujourd'hui deux développeurs payés à temps plein sur le projet.

Des racines communes…

… pour les habitués à Symfony 😊

Une surcouche spécifique !

Et une documentation très accessible…

Ce n'est pas parce qu'il est basé sur les composants de Symfony que vous vous retrouverez à manipuler ces objets directement. Les fonctionnalités sont utilisées mais en étant entièrement décorées par une vision Laravel.
Je trouve ça particulièrement intéressant que Laravel étende ces composants. D'abord parce que c'est un cas concret d'utilisation mais aussi parce que ça montre que la roue n'est pas réinventée inutilement.
Bien sur on peut toujours se poser la question de l'empreinte de Symfony dans l'écosystème PHP, il est presque partout aujourd'hui et peut être considéré en monopole… Mais heureusement il y a d'autres solutions qui continuent d'exister et vivre en dehors de tout ça.
▶ En plus de cette couche, une documentation disponible en ligne permet d'avoir rapidement accès aux exemples et explications utiles à tout développeur. Cette doc est un des gros avantages du projet, elle est simple et va à l'essentiel. Tout est centralisé à un seul endroit et le niveau de langage utilisé est très accessible.

Tout est dans la boite

▶ composer.json
▶ .env
▶ ORM (ActiveRecord) + Migrations
▶ CLI
▶ Templates
▶ Intégration frontend (Elixir)

Laravel est un framework complet qui peut être utilisé pour travailler de manière efficace et dans un cadre fiable, respectant les dernières pratiques en matière de développement.
▶ Gestion de dépendance, ▶ configuration par environnement, ▶ manipulation des données par un modèle objet, ▶ outil en ligne de commande pour les tâches courantes, ▶ langage de template, ▶ intégration avec la couche frontend grâce à un package nommé Elixir.
Tout ces points sont décrits dans la documentation en ligne et nous n'allons pas rentrer dans tout le détail.
Bien sur, son architecture, ses dépendances, et sa philosophie lui sont propre et il faut apprendre à les découvrir et les utiliser.
Comme n'importe quel outil il n'apporte pas de réelle solution, seulement une approche technique. Libre à l'utilisateur d'en faire quelque chose !

Un peu de contexte

                            
# Création d'un projet vierge
composer create-project laravel/laravel
                            
                            
# Démarrage du serveur web intégré à PHP
./artisan serve

# Homepage: http://localhost:8000

Arborescence

                                
├── app
│   ├── Console
│   │   └── Kernel.php
│   ├── Exceptions
│   ├── Http
│   │   ├── Controllers
│   │   ├── Middleware
│   │   └── Kernel.php
│   ├── Providers
│   └── User.php
├── bootstrap

                                
├── config
│   ├── app.php
│   └── …
├── database
│   ├── migations
│   ├── seeds
├── routes
│   ├── api.php
│   ├── web.php
│   └── …
├── public
├── resources
└── storages

Un petit tour d'horizon de l'arborescence de répertoire…
On peut noter qu'elle est plutôt standard par rapport à ce qui se fait aujourd'hui. Tout le code applicatif se trouve dans le dossier `app` qui porte plutôt bien son nom.
Quelques infos sur les `Providers`, ce sont les objets qui vont contenir la configuration du conteneur d'injection de dépendances et des différents services. On aura par exemple le RouteServiceProvider pour le routing, EventServiceProvider pour les évènements applicatifs…
La définition des routes et de la configuration générale est entièrement faite en PHP .
Les prochaines slides vont mentionner du code, nous allons principalement naviguer entre les dossiers routes et app.
J'ai choisi de vous montrer comment gérer un upload de fichier.

Une première version

                            //routes/api.php
Route::post('/upload', function() {
    request('image')->store('images');
});

Facades 🤔

                            Route::post('/upload', function() {
    ...
});

On voit que la route est définie à l'aide d'une fonction statique, il s'agit des fameuses facades de Laravel. Pour ceux qui n'en ont pas entendu parler, ces sont des proxy vers des services déclarés dans le coeur de l'application.
Pour la déclaration des routes c'est pratique, pour le reste je préfère les éviter au maximum !
Ensuite, on peut voir que le code exécuté est déclaré sous la forme d'une fonction anonyme sans paramètre, on est sur le plus basique possible. Je ne suis pas particulièrement fan des fonctions anonymes parce qu'elles déclarent des entités dans notre code complètement dynamique. Il me semble que leur contenu est quand même géré par OPCache, à confirmer…

Helpers 😱

                            /** @var UploadedFile */
request('image')->store('images');

Enfin la fonction `request`, c'est pour moi le pire. Cette fonction cache un appel direct au conteneur pour récupérer l'instance courante de requête. Dedans elle le contenu de la clé 'image' et nous retourne son contenu. Ici, par chance il s'agit d'un objet UploadedFile qui dispose d'une méthode "store" et donc mon code fonctionne.
Je dis bien par chance, ici rien n'assure que la clé 'image' existe ou est bien un fichier uploadé.
Ces helpers sont à éviter absolument. Trop de comportement cachés, les différentes couches de l'application sont complètement transpercées pour récupérer ce dont nous avons besoin.
Heureusement, il y a d'autres solutions pour arriver à ce résultat.

… not so bad !

Injection

                            use Illuminate\Http\Request;

Route::post('/upload', function(Request $request) {
    $request
        ->file('image')
        ->store('images');
});

Validation

                            Route::post('/upload', function(Request $request) {
    $request->validate([
        'image' => 'required|image'
    ]);

    $request->file('image')->store('images');
});

Ensuite, utiliser une information provenant de la requête est risqué dans le sens ou on ne maitrise pas le contenu de se que l'on va lire.
Laravel embarque une API de validation utilisant une syntaxe assez simple. Il suffit de décrire les règles à appliquer séparées par des pipes dans une chaine de caractères.
Ici par exemple, je veux m'assurer que l'entrée "image" de ma requête est bien présente et qu'il s'agit d'une image.
Il existe tout un tas de règles qui répondent à la plupart des besoins et il est possible d'étendre pour des cas plus spécifiques.
La fonction "validate" déclenche une exception si les règles ne sont pas respéctées. Cette exception sera transformée en erreur HTTP 422, Unprocessable entity par le Kernel de Laravel et donc permettrant à l'appelant de bien comprendre ce qui coince.
On limite les cas d'erreur possible tout en garantissant un comportement cohérent de l'application.

Contrats

                            use Illuminate\Contracts\Filesystem\Filesystem;

Route::post(
    '/upload',
    function(Request $request, Filesystem $filesystem) {
        //[...] Validation

        $file = $request->file('image');
        $filesystem->put(
            sprintf('images/%s', $file->hashName()),
            $file
        );
    }
);

Les contrats sont des interfaces intégrées au coeur de Laravel. Ces interfaces décrivent la plupart des comportements interne au framework : génération d'URL, authentification, base de données, encryption, etc.
Ensuite elles peuvent être associées à des implémentations dans le conteneur de l'application.
Ici par exemple, comme nous sauvegardons le fichier envoyé dans un dossier local, nous manipulons le système de fichier. Je choisis donc d'injecter un instance de Filesystem dans mon action.
Je n'ai rien besoin de plus que déclarer cette nouvelle dépendances parce qu'une implémentation par défaut est configurée dans le framework. Le choix du par défaut peut être modifié facilement dans la configuration.
La méthode "store" que nous utilisions précédemment était un raccourci pour cette injection de dépendance, mais elle cachait entièrement la logique et l'utilisation de cet objet. Personnellement je n'aime pas trop quand le framework contrôle tout.

Separation of concerns

Chaque chose à sa place…

…Contrôleur, Route, Service.

La voix du sage vous dira toujours de garder votre code le plus simple et compréhensible possible.
▶ Pour ça j'aime que les choses soient à leur place, chaque objet contenant uniquement le strict minimum.
▶ D'abord le contrôleur, il va contenir le code permettant d'exécuter notre action. Ici nous voulons "simplement" stocker le fichier uploadé.
▶ Ensuite, la route, doit être définie simplement avec l'URL et le contrôleur qui sera exécuté.
▶ Et enfin les services, je n'aime pas ce terme mais je n'en ai pas trouvé d'autre regroupant tout les objets utiles au fonctionnement de notre action. En fait ils lui rendent service pour aboutir au résultat final.

Contrôleur

                                namespace App\Http\Controllers\Api\User;

class UploadProfilePicture
{
    private $filesystem;

    public function __construct(Filesystem $filesystem) {
        $this->filesystem = $filesystem;
    }

    public function __invoke(Request $request) {
        // Action…
    }
}

                                namespace App\Http\Controllers\Api\User;

class UploadProfilePicture
{
    private $filesystem;

    public function __construct(Filesystem $filesystem) {
        $this->filesystem = $filesystem;
    }

    public function __invoke(Request $request) {
        // Action…
    }
}

                                namespace App\Http\Controllers\Api\User;

class UploadProfilePicture
{
    private $filesystem;

    public function __construct(Filesystem $filesystem) {
        $this->filesystem = $filesystem;
    }

    public function __invoke(Request $request) {
        // Action…
    }
}

Un contrôleur est un objet contenant une ou plusieurs méthodes. Une méthode sera définie comme action et donc liée à la route.
Par convention ces objets sont placés dans le dossier "app/Http/Controllers". J'ai choisi de créer un objet invokable, donc utilisant la méthode __invoke. Pour ceux qui ne connaitraient pas, cette méthode permet d'appeler l'objet comme une fonction.
L'avantage ici est que cette unique méthode sera l'unique action de mon objet. Je préfère créer un contrôleur par action, embarquant toute la logique utile à son exécution.
▶ On retrouve l'injection du Filesystem mais cette fois si dans le constructeur. Je trouve ça plus compréhensible de mettre dans le constructeur les services et dans l'action ce qui est lié à la requête et à la route.
▶ Enfin notre action qui prend en paramètre la requête. Je n'ai pas repêté le code ici par manque de place mais on retrouve la validation et le stockage du fichier.

Route

                            Route::post(
    '/upload',
    'Api\User\UploadProfilePicture'
);

Services et conteneur

Les services sont des objets…

… construits et gérés par le conteneur …

… injectés à l'exécution.

Définition `AppServiceProvider::boot`

                                use Illuminate\Contracts\Filesystem\Filesystem;
use Illuminate\Filesystem\FilesystemManager;
use Illuminate\Foundation\Application;

$this->app->bind(
    Filesystem::class,
    function(Application $app) {
        return $app
            ->make(FilesystemManager::class)
            ->disk('local');
    }
);

                                use Illuminate\Contracts\Filesystem\Filesystem;
use Illuminate\Filesystem\FilesystemManager;
use Illuminate\Foundation\Application;

$this->app->bind(
    Filesystem::class,
    function(Application $app) {
        return $app
            ->make(FilesystemManager::class)
            ->disk('local');
    }
);

                                use Illuminate\Contracts\Filesystem\Filesystem;
use Illuminate\Filesystem\FilesystemManager;
use Illuminate\Foundation\Application;

$this->app->bind(
    Filesystem::class,
    function(Application $app) {
        return $app
            ->make(FilesystemManager::class)
            ->disk('local');
    }
);

Les définitions sont écrites en PHP dans les ServiceProviders. Pour tout ce qui est lié à l'application j'ai tendance à utiliser AppServiceProvider. Dans la méthode boot on va placer ce genre de code pour dire au conteneur ce qu'on veut.
▶ En combinant avec les contrats, on peut entièrement piloter l'application. Ici je décide de l'instance par défaut de Filesystem utilisée par Laravel.
Une fonction anonyme me permet de décider comment sera créée mon instance. On voit qu'un objet Application est passé en paramètre de cette fonction. Cette application est notre conteneur, je vais donc pouvoir l'utiliser pour paramétrer mon instance.
▶ Je créé grâce au FilesystemManager, qui est une factory de Filesystem, une instance du disque "local" que je retourne. Le nom local est définit dans la configuration du projet, je ne fais que l'utiliser ici.
Cette technique est pratique mais je peux avoir envie d'un peu plus de précision. Ici je déclare globalement pour toute l'application.

Contextual Binding

                                ...
use App\Http\Controllers\Api\User;

$this->app
     ->when(User\UploadProfilePicture::class)
     ->needs(Filesystem::class),
     ->give(function(Application $app) {
        return $app
            ->make(FilesystemManager::class)
            ->disk('local');
     });

                                ...
use App\Http\Controllers\Api\User;

$this->app
     ->when(User\UploadProfilePicture::class)
     ->needs(Filesystem::class),
     ->give(function(Application $app) {
        return $app
            ->make(FilesystemManager::class)
            ->disk('local');
     });

                                ...
use App\Http\Controllers\Api\User;

$this->app
     ->when(User\UploadProfilePicture::class)
     ->needs(Filesystem::class),
     ->give(function(Application $app) {
        return $app
            ->make(FilesystemManager::class)
            ->disk('local');
     });

                                ...
use App\Http\Controllers\Api\User;

$this->app
     ->when(User\UploadProfilePicture::class)
     ->needs(Filesystem::class),
     ->give(function(Application $app) {
        return $app
            ->make(FilesystemManager::class)
            ->disk('local');
     });

Si je ne souhaite pas modifier le comportement global du framework, je peux utiliser une définition contextuelle dans mon conteneur. L'avantage est de pouvoir gérer très finement les instances utilisées par certains objets.
Toute mon application ne va peut être pas utiliser le même Filesystem.
Ce code sera toujours placé dans le AppServiceProvider. ▶ La fonction when, détermine quand ou plutôt qui sera touché par cette règle. Ici c'est notre contrôleur.
▶ Ensuite la fonction needs, cible un type d'objet à injecter.
▶ Enfin on retrouve dans la fonction give le code d'initialisation de notre objet.
On lit donc, quand notre contrôleur a besoin d'un objet Filesystem alors on lui donne une instance du disque local.
Il y a d'autres façon encore d'utiliser le conteneur mais je vous laisserai aller regarder dans la documentation si vous voulez aller plus loin.

Valider en amont de l'action

Arrêter le processus le plus tôt possible…

… Middlewares et FormRequest.

Middlewares ?

Centraliser les comportements…

FormRequest

./artisan make:request UploadUserProfile

                                namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\UploadedFile;

class UploadUserProfile extends FormRequest
{
    public function rules() {
        return ['image' => 'required|image'];
    }

    public function image(): UploadedFile {
        return $this->validated()['image'];
    }
}

                                namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\UploadedFile;

class UploadUserProfile extends FormRequest
{
    public function rules() {
        return ['image' => 'required|image'];
    }

    public function image(): UploadedFile {
        return $this->validated()['image'];
    }
}

                                namespace App\Http\Requests;

use Illuminate\Foundation\Http\FormRequest;
use Illuminate\Http\UploadedFile;

class UploadUserProfile extends FormRequest
{
    public function rules() {
        return ['image' => 'required|image'];
    }

    public function image(): UploadedFile {
        return $this->validated()['image'];
    }
}

Les objets FormRequest, comme leur nom l'indique sont adaptés aux requêtes liées aux formulaires. Ils ont été ajouté dans Laravel pour faciliter la validation des requêtes.
On peut utiliser la commande artisan pour pouvoir créer facilement une nouvelle FormRequest. Un nouveau fichier PHP est ensuite ajouté dans le dossier app/Http/Requests avec un squelete à remplir.
▶ Voici ce que donnerait la validation de notre requête.
▶ La méthode rules contient le tableau de règles à appliquer au validateur. Pour rappel veut s'assurer que la clé "image" est bien présente et est une image valide. Ces règles de validation seront exécutées avant d'atteindre le contrôleur, c'est exactement ce que nous cherchons.
▶ Enfin je rajoute une méthode sur mon objet FormRequest pour m'aider à facilement accéder aux éléments qui m'intéressent, ici le fichier uploadé. Grâce au typage de retour introduit en PHP7, je force PHP à s'assurer que le champ image est bien une instance d'UploadedFile.
Je vais avoir besoin d'utiliser des méthodes sur cet objet, il faut que je m'assure qu'il est bien ce qu'il est. Je ne me prive jamais d'utiliser le typage aussi bien en paramètre qu'en retour. Un code qui déclare ces types est un code plus clair.
Maintenant que nous avons définit tout ce qu'il faut, revenons au contrôleur.

Contrôleur

                                namespace App\Http\Controllers\Api\User;

use App\Http\Requests\UploadUserProfile;

class UploadProfilePicture
{
    public function __construct(Filesystem $filesystem)
    {
        $this->filesystem = $filesystem;
    }

    public function __invoke(UploadUserProfile $request)
    {
        $image = $request->image();
        $this->filesystem->put('images', $image);
    }
}

                                namespace App\Http\Controllers\Api\User;

use App\Http\Requests\UploadUserProfile;

class UploadProfilePicture
{
    public function __construct(Filesystem $filesystem)
    {
        $this->filesystem = $filesystem;
    }

    public function __invoke(UploadUserProfile $request)
    {
        $image = $request->image();
        $this->filesystem->put('images', $image);
    }
}

La version finale de cet objet utilise tout les éléments déclarés précédemment. L'objet Filesystem est injecté par le Contextual Binding, et j'ai remplacé l'injection de l'objet Request par l'objet FormRequest.
▶ On peut récupérer sans crainte le contenu grâce à la méthode image et l'utiliser pour sauvegarder le fichier.
L'action contient finalement deux lignes de code contre une pour la version ugly. Bien sur nous avons rajouté plusieurs éléments autour pour stabiliser et valider le comportement.

🧁 Cerise sur le gâteau !

Vous pouvez désactiver les facades !

                                /* config/app.php */
[
    /*
    |--------------------------------------------------------------------------
    | Class Aliases
    |--------------------------------------------------------------------------
    |
    | This array of class aliases will be registered when this application
    | is started. However, feel free to register as many as you wish as
    | the aliases are "lazy" loaded so they don't hinder performance.
    |
    */

    'aliases' => [
        …
    ],
]

Si vraiment utiliser les facades vous exaspère, il est possible de les désactiver. Cette manipulation n'empêchera pas le framework de fonctionner correctement mais interdira aux développeur des les utiliser !
Dans le fichier de configuration config/app.php, il suffit de chercher la clé aliases et de vider le tableau qu'elle contient. Cette clé de configuration déclare tout les symbole qui pourront être utilisé comme facade.
Simple et rapide, ensuite plus de raison de s'arracher les cheveux !

Et voilà !

Une micro application,
Testable, maintenable,
Et surtout pas de magie !

Super, nous venons de terminer d'implémenter notre contrôleur.
▶ Nous venons de créer une mini application.
▶ Elle est facilement testable en injectant des Mock dans notre contrôleur et la maintenance est facilité car chaque partie du code est à sa place, légère et concise.
▶ Ce qu'il faut retenir de plus important par rapport à la version ugly, c'est qu'il n'y a pas de magie. Tout ce qui est magique est à proscrire absolument.
Ce que j'entends par magie correspond à tout ce qui se passe et qu'on ne contrôle pas ou ne comprends pas.

Au final…

Laravel est un outil et seulement un outil …
Très rapide pour prototyper …
Très riche en fonctionnalités par défaut …
Mais pas adapté à tout les cas !

Finalement après ces différentes étapes, voici selon moi les principaux avantages de Laravel.
▶ Ce n'est qu'un outil, libre à l'utilisateur de s'en servir de la bonne façon.
▶ Il est possible de créer une application très rapidement en utilisant les outils intégrés.
▶ Il embarque beaucoup de fonctionnalités par défaut, envoi de mail, notification, websocket, queue, etc. Tout ces éléments sont présents, il suffit de les configurer pour les utiliser.
▶ Il n'est cependant pas adapté à tout les cas. Chaque outil a ses forces et faiblesses, aujourd'hui j'utilise Laravel sur des projets en production, Symfony sur d'autres. Il faut essayer de prendre du recul pour tirer avantage de la meilleure solution en fonction du contexte et du projet.

Attention à…

Ne pas prendre tout les raccourcis possible…
Prendre le temps d'apprendre…
Comprendre l'architecture de votre code.

Un dernier point sur ce qui amène selon moi les incompréhensions et certaines versions ugly dans un projet.
▶ Il faut éviter de prendre les raccourcis, surtout s'ils sont trop simple. J'entends par la que chaque choix à ses conséquences, il faut éviter de cacher la complexité quand on peut.
▶ Toujours prendre le temps d'apprendre, se documenter, lire la documentation. Souvent ça permet d'avoir une vision plus globale et donc de prendre de meilleures décisions.
▶ Et enfin, il ne faut jamais jamais écrire du code que l'on ne comprend pas. C'est le meilleure moyen d'arriver à une solution bancale, difficile à faire évoluer.

https://joind.in/talk/a77e5

Laravel

Stéphane Hulard

Laravel ?

Un peu d'histoire…

Des racines communes…

Une surcouche spécifique !

Tout est dans la boite

Un peu de contexte

Arborescence

Une première version

Facades 🤔

Helpers 😱

Injection

Validation

Contrats

Separation of concerns

Contrôleur

Route

Services et conteneur

Définition AppServiceProvider::boot

Contextual Binding

Valider en amont de l'action

Middlewares ?

FormRequest

Contrôleur

🧁 Cerise sur le gâteau !

Et voilà !

Au final…

Attention à…

Définition `AppServiceProvider::boot`