Le site WebSocket protocole (WS) permet d'échanger des données entre un navigateur et un serveur via une connexion persistante. Les données y sont transmises dans les deux sens sous forme de "paquets" sans rupture de la connexion et sans requêtes HTTP supplémentaires.
WebSocket convient bien aux services de communication permanente, tels que les salons de discussion, les jeux en ligne, les marchés en temps réel, etc.
À titre d'exemple, créons un backend pour un simple chat. Il est nécessaire de fournir les fonctionnalités de base :
- L'envoi de messages au chat.
- Détermination de l'identité de l'auteur du message.
- Notifications d'action. Par exemple, un nouveau membre rejoignant le chat, quittant le chat, indicateur de frappe (quelqu'un est en train de taper...).
Modèle de base de données
Commençons par créer un modèle pour la base de données. Même si nous ne prévoyons pas initialement de stocker les messages et l'historique de la correspondance dans la base de données, nous avons quand même besoin d'un modèle pour structurer l'envoi des messages et des notifications.
Créons un modèle générique chat_event générique qui contient
- Relation avec l'utilisateur. Tout message comprend des informations sur l'utilisateur auquel il se réfère.
- Type (enum) un champ avec 4 options possibles. Connected et Disconnected - pour les notifications lorsqu'un utilisateur est connecté ou déconnecté. Typing - pour indiquer que l'utilisateur est en train de rédiger un nouveau message. Message - pour un message texte standard.
- Message (text) - le texte du message.
Configuration des points d'extrémité
L'étape de développement suivante est légèrement différente de l'approche standard commune aux autres fonctionnalités de l'application. Habituellement, un processus métier est créé, puis un point de terminaison est configuré pour l'exécuter. Dans le cas des WebSockets, tout se passe différemment, et le point de départ est la création d'un point de terminaison basé sur les déclencheurs des processus métier qui sont ensuite créés.
Nous avons besoin d'une section endpoint. C'est là que nous créons un nouveau point de terminaison en sélectionnant l'option appropriée. WebSocket Endpoint.
Pour les WebSockets, il n'y a pas de choix de méthode de requête - c'est toujours GET. Spécifions une simple URL - /chat/ et créons un groupe pour lui avec le même nom.
Ensuite, nous devons créer des variables qui détermineront le format d'échange de données au sein de la WebSocket.
- Client-to-Server. Similaire aux paramètres entrants pour les processus commerciaux standard. Dans notre exemple, nous allons créer un simple message variable de type texte (nous enverrons des messages texte ordinaires au serveur).
- Server-to-Client. Ici, les variables sont créées pour les messages du serveur, envoyant des données du serveur à l'utilisateur. Notez que ce n'est pas la même chose qu'une réponse à une demande de l'utilisateur. Et bien qu'il puisse être envoyé en réaction à des actions de l'utilisateur, il est plus souvent causé par des événements externes. Dans notre exemple, le serveur enverra des notifications de tous les événements du chat, nous allons donc définir le modèle chat_event en tant que variable.
Après avoir créé les variables, vous pouvez passer à l'essentiel : créer la logique de la WebSocket. Elle est basée sur des déclencheurs qui se déclenchent lorsqu'un nouveau message est reçu sur une WebSocket, ainsi que lorsqu'une connexion est établie ou déconnectée.
Création d'un processus métier
Utilisons le déclencheur connect et créons un processus métier pour celui-ci. Il sera lancé au moment où l'utilisateur établit une connexion avec la WebSocket, et sa tâche sera d'envoyer une notification à ce sujet à tous les utilisateurs connectés.
Notez que le bloc de démarrage comprend deux paramètres User ID et Connection ID. Ainsi, vous pouvez non seulement déterminer immédiatement l'utilisateur qui a établi la connexion mais aussi obtenir un identifiant unique pour cette connexion. À l'avenir, cet identifiant pourra être utilisé, par exemple, pour envoyer des messages ciblés ou pour mettre fin à la connexion de manière forcée.
Сreate toutes les étapes nécessaires du processus métier :
- Make User. Utilisons le paramètre de départ User ID pour créer un modèle d'utilisateur.
- Make chat_event. Сreate a event notification model. Nous le connecterons à l'utilisateur en utilisant le modèle créé à l'étape précédente et nous sélectionnerons également le type d'événement et le paramètre. Type = Connected. Nous n'utilisons pas le paramètre message puisque, dans ce cas, ce n'est pas un message qui est transmis mais une notification de connexion.
- WSS Connections /chat/. En utilisant ce bloc, nous obtiendrons une liste de toutes les connexions WebSocket actives.
- For Each Loop. Nous utilisons le tableau des connexions comme paramètre de boucle, en envoyant des notifications à chaque utilisateur connecté.
- Expand WebSocket Connection. Développez les informations de connexion pour obtenir le Connection ID.
- WSS Send /chat/. Nous utilisons le tableau Connection ID et l'élément chat_event pour envoyer la notification.
Utilisation de Postman pour tester les WebSockets
À ce stade, la WebSocket, bien qu'elle n'ait pas de fonctionnalité significative, est déjà opérationnelle et peut être testée en pratique. Pour ce faire, vous pouvez utiliser n'importe quel outil qui vous permet de travailler avec des WebSockets. Voyons comment le faire avec l'outil Postman à titre d'exemple.
Il faut cliquer sur le bouton New button et sélectionnez WebSocket Request
Vous devez spécifier l'URL de la WebSocket. Vous pouvez la trouver en utilisant Swagger, où la WebSocket se trouve dans la liste avec le reste des points d'extrémité.
Contrairement aux demandes standard, les WebSockets fonctionnent en utilisant le protocole wss et vous devez donc remplacer https par wss. Le résultat devrait être une URL similaire : wss://qvlxglh-app.apms.io/api/chat/
Ensuite, vous devez ajouter un jeton d'authentification à la requête puisque la connexion ne peut pas être anonyme. Vous devez créer un en-tête Authorization avec une valeur comme Bearer lBCiunRWg6BfogDrLml4jrC4iJiWucKo. Au lieu de lBCiunRWg6BfogDrLml4jrC4iJiWucKo, vous devez insérer votre propre jeton, qui peut être obtenu à la suite d'une autorisation (POST /auth/ endpoint).
Si tout est fait correctement, alors en cliquant sur le bouton Connect une connexion sera établie et le premier message sera reçu du côté serveur, le processus d'affaires pour l'envoi ayant été créé précédemment.
En même temps, vous pouvez vous assurer que la réception de messages du serveur ne se produit pas seulement en réaction à certaines demandes de notre part. Les actions d'autres utilisateurs peuvent les provoquer. Pour tester cela, vous pouvez établir une connexion dans un autre onglet en utilisant le jeton d'authentification d'un autre utilisateur. Un message du serveur le notifiant sera envoyé à tous les onglets avec une connexion active.
Processus de gestion de la messagerie
Vous pouvez maintenant continuer à développer les capacités de la WebSocket et créer un processus commercial pour la messagerie. À propos, vous pouvez envoyer des messages maintenant, mais sans créer d'abord la logique, cela n'a pas de sens, le message ne mènera à aucune réaction. Par conséquent, retournons aux paramètres du point de terminaison et créons un processus d'affaires pour le receive déclencheur.
À bien des égards, il sera similaire au processus opérationnel précédent. Lorsqu'un message est reçu, il sera nécessaire de générer un fichier chat_event et envoyer des notifications à ce sujet à tous les participants au chat. La différence est que le message lui-même devra être ajouté à l'adresse chat_event, et que l'auteur du message n'a pas besoin d'être inclus dans la liste de diffusion.
Les mêmes blocs sont utilisés dans la première partie du processus métier. Dans le bloc Make chat_event vous devez définir type = message et attacher le message lui-même à partir du bloc de départ.
Dans la boucle, il faut vérifier (Equal block) et envoyer le message uniquement si l'ID de connexion du récepteur ne correspond pas à l'ID de connexion de l'émetteur (If-Else = False).
Vous pouvez publier le résultat et commencer à tester. Notez que le message lui-même est au format JSON donc, lorsque vous utilisez la variable message, elle se présente de cette manière :
{"message":"Some text here"}
Dans l'exemple, vous pouvez voir que vous recevez une notification de connexion au chat, que vous envoyez votre propre message (Hi!) et recevez une réponse (Glad to see you!)
Ceci termine la création du backend de base pour le chat en utilisant les WebSockets. Vous pouvez commencer à construire le front-end et développer votre propre application de messagerie en temps réel.
