En travaillant sur le package Bridge Laravel Symfony Serializer, j'ai rencontré une limitation inattendue : les configurations Laravel ne fonctionnent pas avec les objets.
Ce problème m'a amené à examiner de près la façon dont Laravel est construit et à repenser la façon dont nous configurons le framework.
Nous commencerons par identifier le problème, puis examinerons les solutions existantes et enfin proposerons une nouvelle approche.
Ce voyage ne résoudra pas seulement un problème spécifique : il nous donnera de nouvelles perspectives sur le développement et l'évolution du framework.
En tant que développeurs, nous repoussons toujours nos limites. C'est pourquoi nous ne nous en tenons pas uniquement à Laravel : nous explorons des solutions issues d'autres frameworks pour élargir notre perspective.
Prêt à explorer les configurations Laravel en profondeur et à envisager des améliorations potentielles dans la façon dont nous travaillons avec le framework ?
Allons-y !
Avant de nous plonger dans le problème des objets dans la configuration, abordons une question clé : pourquoi Laravel se soucie-t-il de mettre en cache les configurations en premier lieu ?
Chaque fois que quelqu'un visite un site Laravel, voici ce qui se passe en coulisses :
Cela semble simple, non ? Mais il y a un piège.
Décomposons-le avec un exemple réel. Imaginez que votre application comporte 20 fichiers de configuration. Pour chaque requête, Laravel doit :
Cela représente beaucoup de travail, surtout lorsque votre site est occupé. Chaque fichier de configuration nécessite sa propre opération d'entrée/sortie (E/S), et en PHP traditionnel, chaque nouvelle requête HTTP relance tout ce processus.
Voici comment la mise en cache de configuration de Laravel résout ce problème :
Pour les sites Web en ligne, ces améliorations font une grande différence en termes de performances et d’évolutivité de votre application.
Désormais, utiliser des objets dans les configurations peut être génial. Ils offrent des avantages tels que la sécurité des types et la saisie semi-automatique dans votre éditeur de code. Mais voici le problème : ils ne fonctionnent pas bien avec le système de mise en cache de Laravel.
Ce conflit entre accélérer les choses et rendre les configurations plus puissantes est exactement ce que nous allons aborder dans cet article.
Leconfiguration artisanale php : cacheLa commande ne parvient pas à mettre en cache les objets dans les fichiers de configuration.
Par exemple, plaçons plusieurs objets dans leconfig/sérialiseur.phpconfiguration :
?php use Symfony\Component\Serializer\Encoder; return [ // ... 'encoders' =[ new Encoder\JsonEncoder(), new Encoder\CsvEncoder(), new Encoder\XmlEncoder(), ], // ... ];La tentative de mise en cache de cette configuration entraîne une erreur :
/app $ php artisan config:cache LogicException Vos fichiers de configuration ne sont pas sérialisables. sur supplier/laravel/framework/src/Illuminate/Foundation/Console/ConfigCacheCommand.php:73 69▕ require $configPath ; 70▕ } catch (Throwable $e) { 71▕ $this->files->delete($configPath); 72▕ ➜ 73▕ throw new LogicException('Vos fichiers de configuration ne sont pas sérialisables.', 0, $e); 74▕ } 75▕ 76▕ $this->components->info('Configuration mise en cache avec succès.'); 77▕ } 1 bootstrap/cache/config.php:807 Erreur ::("Appel à la méthode non définie Symfony\Component\Serializer\Encoder\JsonEncoder::__set_state()") +13 frames du fournisseur 15 artisan:35 Illuminate\Foundation\ Console\Kernel::handle(Object(Symfony\Component\Console\Input\ArgvInput), Objet(Symfony\Component\Console\Output\ConsoleOutput))Inattendu, non ? Déballons ce qui se passe.
Tous les fichiers de configuration se trouvent dans le/configdossier dans le répertoire racine du projet.
Ces fichiers contiennent des paramètres pour divers aspects du framework, tels que la base de données, la mise en cache, les sessions et d'autres composants.
Lorsque l'application est initialisée, Laravel charge tous les fichiers de configuration de ce répertoire et les combine en un seul tableau de configuration.
Ce tableau est rendu disponible via la variable globale$app['config']dans le conteneur d'application.
Les développeurs peuvent accéder aux configurations depuis n'importe où dans l'application de trois manières :
// Utilisation de `Facade` $timezone = Config::get('app.timezone'); // Utilisation de la fonction d'assistance $timezone = config('app.timezone'); // Directement sur le conteneur $timezone = $app['config']->get('app.timezone');Pour les développeurs de packages, les configurations peuvent être publiées dans le répertoire de l'application./configannuaire:
$ php artisan supplier:publish \ --provider="WayOfDev\Serializer\Bridge\Laravel\Providers\SerializerServiceProvider" \ --tag="config"Cela permet aux utilisateurs du package de personnaliser facilement son comportement dans leurs applications.
Ce système offre une flexibilité dans la gestion des paramètres de l'application, mais, comme nous le verrons plus tard, il peut créer des problèmes lors de la tentative de mise en cache des configurations avec des objets.
Par défaut, Laravel lit tous les fichiers de configuration du/configrépertoire à chaque demande.
Pour optimiser ce processus et améliorer les performances, le framework fournit un mécanisme de mise en cache de configuration.
Pour créer une version mise en cache de toutes les configurations, utilisez la commande :
configuration artisanale php : cacheCette commande effectue les opérations suivantes :
/configannuaire/bootstrap/cache/config.phpLe fichier cache résultant ressemble à ceci :
?php return array( 0 ='hashing', 9 => 'diffusion', 10 => 'view', 'app' => array( 'name' => 'laravel', 'env' => 'local', 'debug' =...
[Courte citation de 8% de l'article original]