Asynchrone avec Symfony Messenger et Mercure

Transcript

1. Asynchrone avec Messenger et Mercure AFUP Day Tours 2020 - Grégoire Pineau - @lyrixx Dev @JoliCode CoreTeam @Symfony
2. Qu’est ce que l’asynchrone ? Pourquoi faire de l’asynchrone ? Prenons un exemple
3. Démo : Un écran d’import de CSV
4. Un chargement synchrone Problème : mode synchrone • L’utilisateur doit attendre que la requête soit traitée • S’il change de page, l’import sera en échec • Le nombre de workers PHP (FastCGI ou mod_php) est une ressource limitée ⛈ Solution : mode asynchrone • Le traitement sera relégué en arrière plan • Par un autre processus : plus de problème avec FastCGI ou mod_php • Éventuellement sur une autre machine
5. Problème : mode synchrone
6. Solution : un traitement asynchrone
7. Faire de l’asynchrone • Meilleur temps de réponse • Facilite la scalabilité • Gestion des erreurs simplifiée • DX / Ops plus compliqué • Les actions ne sont plus “temps réel” • UX dégradée
8. En route vers l’asynchrone
9. Point de départ
10. De la qualité ! Un service “CsvImporter”
11. Symfony Messenger Un composant pour faire de l'asynchrone
12. Messenger ? • Message Bus ◦ Command Bus ◦ Event Bus ◦ Query Bus ◦ Oui Bus (Merci Damien )
13. Messenger On dispatch un message dans le bus Le bus route le message vers un handler Messenger agit comme un “man in the middle”
14. bin/console make:message CsvUploaded
15. Dispatch du message dans le Bus
16. Centraliser tous les messages via un bus, quelles conséquences ? • Logger chaque message • Valider les messages • Wrapper chaque handler dans une transaction SQL • Stocker le message quelque part… et ensuite exécuter une commande pour lire et traiter le message
17. Les Transports
18. Les transports : où lire / écrire les messages
19. Configuration
20. Le Routing
21. Le routing
22. Gérer les messages dans la queue (worker)
23. L’upload n’est plus effectué
24. Le message est dans la queue
25. bin/console messenger:consume
26. ET VOILÀ ! Merci En fait non, il y a encore un tout petit peu de boulot
27. Travailler avec les workers
28. Des daemons pour les workers en production • SystemD - ou le superviseur de votre OS • Supervisord • Gérer par votre PaaS (Symfony Cloud, Heroku, Clever Cloud, …) Pensez à redémarrer les workers à chaque déploiement Exécuter autant de worker que nécessaire (scaling) Ne pas ajouter plus de worker sur une machine si elle est déjà CPU bounded
29. Les options
30. Échecs et nouvelles tentatives
31. En cas d’erreurs
32. Transport d’échec
33. De nouvelles commandes
34. De nouvelles commandes
35. Faux transports
36. Il existe de faux transports • sync:// Gère les messages de manière synchrone (dev) • in-memory:// Ne dispatch pas les messages aux handlers (test)
37. Et ensuite ?
38. Quelques remarques • Gestion des fichiers : local, NFS, distant, ou via la queue ? • Un message peut-il publier à son tour un message ? • Il faut monitorer la taille des queues, surtout celle “failed” ◦ Et pourquoi pas faire un écran dans l’admin du site
39. Et plus encore • Intégration avec PHP Enqueue ◦ Kafka ◦ Amazon SQS ◦ Google Pub/Sub • Serialization de message • Middlewares et Event • Envelopes & Stamps • ApiPlatform Integration
40. Démo : Pas de feedback !
41. Une expérience utilisateur dégradée Comme l’import de données est asynchrone, l’utilisateur n’a aucun feedback : • Est-ce que l’import est en cours ? • Est-ce que l’import est fini ? • Est-ce que l’import s’est bien terminé ? Il faut donner un feedback à l’utilisateur en temps réel
42. Mercure Un serveur pour donner du feedback
43. Démo : Du feedback !
44. Comment pousser de la donnée vers le client ?
45. Les bénéfices des websockets • Communication Full Duplex • Bas niveau : contrôle total Les websockets VS SSE ? Les inconvénients des websockets • Bas niveau, donc à implémenter : ◦ Authentification ◦ Reconnexion ◦ Historique des messages “perdus” • Déprécié par HTTP 2 et 3 • Dur à sécuriser
46. Mercure : Un nouveau protocole • Une spécification sur IEFT (encore en draft) • Full Duplex ◦ Publish : HTTP POST ◦ Subscribe : SSE • Nativement: reconnexion, récupération des messages “perdus”, historique • Auto découvrable : fait pour REST & GraphQL • Sécurisé avec JWT • Conçus pour les scripts avec une courte durée de vie: PHP, FastCGI, Serverless • Support du chiffrage End2End
47. Il existe un polyfill pour IE 5.5+
48. Mercure : son workflow
49. Comment publier avec Symfony
50. Configuration de Symfony
51. Publier sur le hub
52. Un UUID pour l’import
53. Comment consommer depuis un navigateur
54. Connexion au Hub Mercure en JavaScript
55. Lecture des messages
56. Sécurité
57. La sécurité • Mercure utilise JWT (JSON Web Token) • Le publisher doit être authentifié • Un subscriber ◦ Peut être anonyme (si la configuration l'autorise) ◦ Doit être authentifié pour recevoir du contenu privé • Un update peut cibler une ou plusieurs target • Deux transports : cookie ou Authorization header
58. Le serveur (hub)
59. Le serveur (hub) • Il existe une implémentation de référence (en Go) ◦ Rapide ◦ Fonctionne partout (binaire statique et docker) ◦ HTTP 2 et HTTPs (via let’s encrypt) ◦ Support de CORS + CSRF ◦ Cloud native (12Factor app) ◦ Open Source (AGPL) • Il existe au moins une autre implémentation ◦ En JavaScript https://github.com/Ilshidur/node-mercure
60. Conclusion
62. Conclusion • Messenger ◦ Simple à mettre en place (en dev et en prod) ◦ Son utilisation est facile ◦ Le composant est flexible ◦ Permet de décharger le front au profit de worker ◦ Le composant est stable • Mercure ◦ Simple à mettre en place (en dev et en prod) ◦ Il existe une version managée ◦ Donne du feedback à l’utilisateur ◦ Améliore la DX
63. Vous avez aimé la démo ? Retrouver le code sur github : https://github.com/lyrixx/async-messenger-mercure
64. Merci AFUP Day Tours 2020 - Grégoire Pineau - @lyrixx Dev @JoliCode CoreTeam @Symfony