Le composant Messenger de Symfony est sorti il y a maintenant 3 ans avec Symfony 4.1. C’est un outils très utile pour faire des traitements asynchrones. Un des points faible de l’asynchrone est qu’il est plus compliqué a debugger, car le processus est moins linéaire. Dans un traitement synchrone, toutes les fonctions sont appelés les unes après les autres. L’envoi d’un e-mail suite à la soumission d’un formulaire se fait dans le même processus.
Un workflow asynchrone peut employer différents services qui s’occuperont de gérer le message. Pour reprendre l’exemple d’un formulaire, une fois soumis, Messenger envoie un message aux services paramétrés. Leur tâche sera donc de traiter ce message en temps voulu. Généralement le plus rapidement possible. Cette dispersion fait que c’est plus compliqué de débugger un script une fois que le message est envoyé.
Dans mes projets Symfony, je mets certaines tâches en asynchrones : tout ce qui est envoi d’email, tâches lourdes ou qui n’a pas besoin d’être affichée sur-le-champ à l’utilisateur. Cependant au lieu d’utiliser des services, j’envoie ces données dans une queue en base de données afin d’être traité ultérieurement par un worker ou une tâche CRON. Cette méthode est facile à mettre en place et elle ne nécessite pas d’installer d’autres services supplémentaires de queue comme rabbitmq par exemple.
Pour traiter les messages stockées dans la queue en base de données, Symfony nous donne une commande consume. Cette commande peut afficher des logs sur ce qu’il se passe avec l’option -vvv
. Par contre, l’affichage de dump ne marche pas de cette manière, ni de var dump ou d’echo. Car la sortie se fait sur la console. C’est pourquoi je suis arrivé à cette petite astuce qui permet de débugger/logger plus facilement les données traitée.
$input = new ArgvInput();
$output = new ConsoleOutput();
$io = new SymfonyStyle($input, $output);
puis pour utiliser l’output
$io->section('REQUETE');
$io->info(json_encode($body));
Laisser un commentaire