Paramétrez des feedbacks pour vos traitements asynchrones

Quand on doit faire de l’asynchrone, par exemple avec RabbitMQ, en tant que développeur on se retrouve un peu isolé de l’avenir du traitement de son code.

Partons d’un cas réel de site de vente immobilière qui a besoin de générer des images.

On vous demande chaque nuit de récupérer des centaines de dossiers sur un serveur et pour chacun d’importer et traiter des images et des PDFs.

Pour plus de confort pour le client, les images des résidences et les plans de chaque appartement, sont stockés dans le cloud.

Petit calcul :

Partons du principe qu’en moyenne 1 résidence comporte 30 appartements ;

1 résidence = 30 appartements
1 résidence = 4 images de présentation
1 appartement = 1 plan au format pdf

Donc pour une résidence il faut télécharger 4 + 30 fichiers = 34 fichiers !

Suite du calcul :

L’agence immobilière gère en moyenne 200 résidences ;

1 résidence = 34 fichiers
10 résidences = 340 fichiers
...
Donc une agence = 200 * 34 = 6800 fichiers

Ça commence à en faire des fichiers. Si on en vient ensuite à gérer 5 agences, on obtient un total en moyenne de 34 000 fichiers.

Pour une agence, si on devait découper par résidence, on pourrait écrire un traitement asynchrone d’import pour chaque résidence, soit 200 messages à traiter dans RabbitMQ.

Ou 200 * 5 = 1000 messages pour 5 agences.

Voilà pour les chiffres. Admettons que l’application Symfony utilise le Messenger et fasse son job et que le tout est injecté dans un moteur de recherche comme Elasticsearch.

Feedback

On en vient maintenant à la seconde partie de l’article. Celle où on a besoin de feedback. Parce que faire autant de traitements sans avoir de retour d’erreur ou pour nous dire que tout va bien, ça peut vite devenir stressant.

“Est-ce que l’import a marché cette nuit ? Est-ce qu’il y a eu des erreurs pour convertir un PDF en image, si oui lesquelles ? Est-ce que les emails sont partis ? Est-ce que le moteur de recherche est bien à jour ?”

Fabien Potencier nous a dévoilé il y a quelque temps la sortie d’un nouveau composant, Notifier. C’est une super nouvelle, qui arrive trop tard pour notre projet, mais je vous conseille de le suivre de près ! https://symfonycasts.com/screencast/london2019/keynote

Aujourd’hui pour être notifié on a le choix : “email, slack, mattermost, sms…”

On va retenir Slack. Pourquoi ? Tout le monde le connait et reste simple d’utilisation. On peut insérer du texte, des images, faire parler un bot, etc.

On va utiliser la librairie JolieCode SlackPhpApi. L’intérêt de cette librairie c’est que comme ils le disent, le SDK est généré automatiquement depuis Slack API specs via JanePHP.

(ndla: Si vous ne connaissez pas Jane, vous allez sur le slack de Symfony et vous tapez #jane, un bot automatique viendra vous répondre !)

Après avoir installé la librairie, il vous suffit de créer un token depuis Slack, un Bot Token.

Ensuite on peut s’amuser avec l’api ;

Envoyer un fichier txt:

Envoyer un message :

La liste des méthodes est assez longue : https://api.slack.com/methods

Conclusion

Faire de l’asynchrone existe depuis très longtemps, et avec le composant Messenger de Symfony, tout est fait pour nous faciliter la tâche.

La notion de feedback en informatique ne parlera pas beaucoup aux non développeurs, ceux qui ne sont pas responsables du code que vous avez écrit. Quand on s’engage à écrire des workflows asynchrones il faut en assumer la responsabilité tout en arrivant à gérer le stress que cela peut provoquer.

Slack n’est pas un outil de monitoring, c’est un outil pour communiquer et permettre d’avoir des informations à la fois pour vous, et peut-être pour le client. On peut imaginer de générer des rapports d’erreurs (une image cassée) que l’on pourrait envoyer dans Slack pour informer le client.

N’oubliez pas que les traitements en asynchrones ne sont pas à l’abri d’effets de bords : ils peuvent échouer ou ne pas être traités…Voir pire la queue de rabbitMQ s’empile à l’infini ! Heureusement il existe une API Rest pour RabbitMQ que l’on pourrait appeler dans Slack par exemple pour rester informé.

Ps: comme l’a dit @mathiasverraes :

There are only two hard problems in distributed systems: 2. Exactly-once delivery 1. Guaranteed order of messages 2. Exactly-once delivery

— Mathias Verraes (@mathiasverraes) August 14, 2015

N’hésitez pas si vous avez des feedbacks !