Si vous avez bâti des applications ColdFusion pendant un certain temps, vous avez probablement déjà eu cette conversation. « Il nous faut un clavardage de soutien en direct. »
Pas de problème.
« Notre personnel vit déjà dans Slack. »
Encore correct.
« Est-ce que le site Web pourrait juste… parler à Slack d’une façon ou d’une autre? »
Là, on commence à s’en venir.
La plupart des applications répondent à cette exigence en ajoutant une toute nouvelle interface d’administration. Il vous faudra des conversations. Un historique des messages. Des notifications. Des indicateurs de frappe. Des badges de messages non lus. La présence des utilisateurs. L’authentification. Des autorisations. La recherche. Des outils de modération.
Félicitations. Vous venez accidentellement de commencer à écrire Discord.
C’est beaucoup d’efforts d’ingénierie pour résoudre un problème que votre personnel de soutien a déjà réglé il y a des années en vivant dans Slack huit heures par jour. Alors, au lieu d’amener mon équipe de soutien à mon application... j’ai amené mon application à elle.
Ne construisez pas encore un autre centre de réception des messages
Les développeurs adorent construire des choses. Les utilisateurs adorent utiliser des choses qu’ils connaissent déjà. Ce sont souvent des forces opposées.
Si votre équipe de soutien passe déjà ses journées dans Slack, chaque nouvel onglet de navigateur que vous lui forcez à garder ouvert est une chose de plus qu’elle oubliera de vérifier jusqu’à trois heures après que le client se sera tourné vers votre concurrent.
Slack nous donne déjà :
- Des notifications
- La recherche
- Les réactions
- Les fils de discussion
- Des applications mobiles
- Des applications de bureau
- La présence
- L’historique
- La gestion des utilisateurs
C’est une quantité absurde d’infrastructure que nous serions autrement volontaires pour maintenir nous-mêmes. La meilleure interface d’administration est souvent celle que vous n’avez jamais à écrire.
Pensez à Slack comme à votre console d’exploitation
Au lieu de traiter Slack comme une destination de notifications, traitez-le comme une interface utilisateur. Le navigateur devient une extrémité de la conversation. Slack devient l’autre.
Aucun des deux côtés ne sait que l’autre existe (ou ne s’en soucie particulièrement).
Visitor
│
▼
ColdFusion
│
▼
Slack
│
▼
Support StaffChaque message du client apparaît dans Slack. Chaque réponse du personnel repasse par ColdFusion. ColdFusion agit comme le gestionnaire intermédiaire légèrement sarcastique qui s’assure que personne ne dise quelque chose d’embarrassant.
Les fils de discussion sont l’ingrédient secret
Si chaque message client devenait un tout nouveau message Slack, votre canal de soutien ressemblerait à la section des commentaires d’une vidéo YouTube. Un chaos complet. À la place, chaque visiteur commence un fil de discussion.
Customer A
└── Thread
Customer B
└── Thread
Customer C
└── ThreadMaintenant, chaque conversation reste naturellement regroupée. Slack a déjà résolu le problème d’organisation des conversations. Utilisez-le.
L’une des plus grandes leçons de ce projet a été d’apprendre à arrêter de lutter contre la plateforme. Si Slack a une fonctionnalité qui correspond bien à votre problème, laissez Slack faire le travail.
ColdFusion devient le traducteur
L’application n’a en réalité que trois tâches.
1. Recevoir les messages du navigateur
L’utilisateur tape quelque chose. ColdFusion l’enregistre. Puis le transfère à Slack.
2. Recevoir les réponses de Slack
Un représentant du soutien répond dans Slack. ColdFusion reçoit le webhook. Enregistre la réponse. La redélivre au navigateur.
3. Garder tout le monde synchronisé
Aucun des deux côtés ne parle directement à l’autre. Tout passe par ColdFusion. Cela signifie que chaque message est archivé. Chaque conversation peut être auditée. Chaque événement peut être rejoué. Chaque action peut être consignée. Les conversations de soutien cessent de vivre exclusivement à l’intérieur de la plateforme SaaS de quelqu’un d’autre. Slack devient une interface. Votre application demeure le système de référence. C’est une distinction importante.
L’architecture est étonnamment petite
Une chose qui m’a surpris pendant ce projet, c’est à quel point peu d’infrastructure était réellement nécessaire. À un haut niveau, il n’y a que quatre éléments en mouvement.
Browser
│
▼
ColdFusion
│
▼
Slack API
Slack Events
│
▼
ColdFusion
│
▼
BrowserC’est tout. Pas de courtier de messages. Pas de bus d’événements distribué. Pas de cluster Kubernetes maintenu à grand renfort de YAML et d’optimisme. Juste du HTTP dans les deux sens.
Parfois, nous, les développeurs, confondons la complexité avec la sophistication. L’architecture la plus simple qui survit en production gagne généralement.
Pourquoi Slack plutôt que de construire notre propre clavardage?
Parce que le logiciel a un coût d’entretien. Chaque fonctionnalité que nous construisons devient quelque chose que notre Moi du futur devra soutenir. Le David du futur a déjà des problèmes de confiance.
Imaginez écrire votre propre console de soutien. Maintenant, imaginez la maintenir pendant les sept prochaines années. Maintenant, imaginez y corriger des bogues au lieu de travailler sur les fonctionnalités que vos clients paient réellement.
Soudainement, Slack commence à être assez attrayant.
Il y a encore des problèmes à résoudre
Malheureusement, ce n’est pas aussi simple que de publier des messages dans Slack. Vous vous heurtez rapidement à des questions comme :
- Comment savoir à quel fil Slack appartient quel client?
- Comment les réponses trouvent-elles leur chemin vers le bon navigateur?
- Comment empêcher les livraisons en double des webhooks?
- Comment authentifier les requêtes Slack?
- Que se passe-t-il si l’utilisateur actualise la page?
- Que se passe-t-il si le représentant du soutien répond depuis son téléphone?
- Comment reconnecter les utilisateurs après des pannes de réseau temporaires?
Chacune de ces questions devient une décision d’architecture. Certaines sont évidentes. D’autres sont... formatrices. Une ou deux m’ont brièvement fait envisager de devenir éleveur de chèvres.
Une clarification importante
Si vous avez lu le titre de cette série et pensé immédiatement : « Cool. WebSockets. »
Pas tout à fait.
Le résultat final donne l’impression de fonctionner avec des WebSockets. Les messages apparaissent presque instantanément. Les réponses arrivent en temps réel. Le clavardage semble complètement interactif.
Mais en dessous. Ce ne sont pas du tout des WebSockets. C’est construit sur une technologie beaucoup plus simple qui s’entend remarquablement bien avec les applications ColdFusion traditionnelles, les équilibreur de charge existants, les proxys inverses et l’infrastructure HTTP ordinaire. C’est aussi beaucoup plus facile à déboguer lorsque les choses décident inévitablement de s’enflammer à 14 h 17 un mardi après-midi.
Parce que les systèmes de production ne tombent pas en panne à des moments pratiques. Ils attendent que vous expliquiez à quelqu’un que « tout est stable depuis des mois ». Des salauds.
La suite
Cet article a volontairement évité les détails d’implémentation. Avant d’écrire une seule ligne de code, il vaut la peine de comprendre l’architecture et de poser une question plus importante :
Avez-vous vraiment besoin de WebSockets?
Il s’avère que... probablement pas.
Dans le prochain article, nous construirons la couche de communication en temps réel à l’aide de Server-Sent Events, expliquerons pourquoi je l’ai choisie plutôt que les WebSockets, discuterons des compromis et, espérons-le, convaincrons au moins quelques développeurs d’arrêter de foncer vers la solution la plus compliquée à chaque fois que quelqu’un dit le mot « temps réel ».
Parfois, la technologie ennuyeuse gagne. Et franchement, la technologie ennuyeuse est sous-estimée.