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
• 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
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
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
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
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
(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
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
(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
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