L’auteur explique pourquoi il a attendu d’avoir Redis et un worker Messenger avant de migrer vers Symfony Scheduler en production. Selon lui, sans ces deux éléments, le Scheduler ne serait qu’un cron amélioré, sans les fonctionnalités avancées comme l’asynchronicité, la persistance des états ou la gestion des échecs. Il souligne que Symfony Scheduler ne remplace pas cron, mais s’appuie sur une infrastructure adaptée pour offrir des mécanismes de planification robustes.
L’article détaille trois prérequis essentiels avant d’utiliser le Scheduler : un worker Messenger consommant en continu le transport dédié, un transport asynchrone pour éviter les blocages (comme Redis), et un pool de cache non volatile pour stocker l’état des tâches. Sans ces éléments, l’auteur estime que l’on recréerait les limitations des scripts cron, mais avec une complexité inutile.
Enfin, l’auteur illustre son propos avec cinq jobs actuellement exécutés sur son site, montrant comment le Scheduler simplifie la gestion des tâches récurrentes une fois l’infrastructure en place. Il conclut que le Scheduler est pertinent uniquement si l’environnement technique le permet, évitant ainsi les solutions hybrides peu fiables.
L’article explique comment améliorer les performances d’une application Symfony en envoyant les journaux d’audit de manière asynchrone plutôt que synchronisée : dans une approche classique, chaque opération Doctrine déclenche la génération et l’insertion immédiate d’un audit log en base de données, ce qui peut fortement ralentir les requêtes (par exemple en passant d’environ 10 ms à 30–50 ms avec une base distante). La solution proposée consiste à utiliser Symfony Messenger et AuditTrailBundle pour sérialiser les informations d’audit dans un message envoyé vers une file (RabbitMQ, Redis ou Doctrine), puis traité par un worker en arrière-plan qui écrit le log en base, ce qui découple la logique métier des contraintes de conformité et réduit quasiment à zéro l’impact sur le temps de réponse de l’application.
Cet article de Wanadev Digital explique comment utiliser l'Event Bus de Symfony Messenger pour créer une architecture découplée. Il compare l'EventDispatcher et l'Event Bus, soulignant leurs différences fondamentales : synchrone vs asynchrone, couplage faible vs fort, et scalabilité. L'Event Bus permet un traitement asynchrone, une sérialisation des messages, et une meilleure traçabilité. L'article guide pas à pas pour configurer et utiliser l'Event Bus, idéal pour des tâches comme l'envoi d'emails ou la génération de PDF. Prérequis : comprendre les concepts de Commands et Queries.
L'article explique que PHP, traditionnellement synchrone, peut optimiser des tâches comme les requêtes SQL en les exécutant de manière asynchrone. Cela permet de lancer des opérations non bloquantes, comme des requêtes de base de données ou des lectures de fichiers, pendant que d'autres tâches sont traitées. PHP a introduit des fonctionnalités asynchrones dès la version 4.3 avec les streams, et a évolué avec les générateurs en PHP 5.5 et les fibers en PHP 8.1, permettant une meilleure gestion des coroutines. L'EventLoop est présenté comme un modèle efficace pour gérer plusieurs opérations asynchrones en utilisant des callbacks, bien que cela puisse mener à un "callback hell". Les promesses sont proposées comme solution pour simplifier la gestion asynchrone, transformant les callbacks imbriqués en une chaîne de promesses plus lisible. Enfin, l'article compare des bibliothèques comme ReactPHP et Amp pour la gestion des promesses et des coroutines, recommandant ReactPHP pour les promesses et Amp pour une approche plus naturelle avec les coroutines, tout en suggérant Revolt pour l'EventLoop.
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre
Tout est dans le titre... mais il faut avoir des connaissances minimales sur le sujet pour bien suivre
Tout est dans le titre
Tout est dans le titre
Une astuce pour charger un CSS de manière asynchrone
L'auteur explique surtout le concept de l'event loop :)
Une explication des bonnes pratiques pour éviter le "callback hell" en JavaScript
Tout est dans le titre .
Recently I discovered the Process Class which is the perfect way to manage your child processes in a Symfony Command.