Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Web PubSub offre plusieurs moyens d’ajouter une communication en temps réel à une application. Vous pouvez commencer avec des primitives de messagerie flexibles, maintenir un protocole et un modèle de programmation établis, ou utiliser des API conçues pour un scénario d’application spécifique.
Le bon choix vous permet d’éviter de construire ou d’exploiter des capacités qui ne différencient pas votre application. Cet article explique ce que chaque option offre, ce qui reste sous votre contrôle, et où chaque option apporte le plus de valeur.
Choisissez en fonction de ce que vous voulez construire
| Si vous avez besoin de... | Commencez par... | Pourquoi |
|---|---|---|
| Concevoir des comportements personnalisés en temps réel pour les tableaux de bord, les jeux, les notifications, le streaming de jetons IA, la signalisation ou d’autres scénarios applicatifs | Web PubSub (service de base) | Vous contrôlez le protocole applicatif et la logique métier tandis qu’Azure gère les connexions et la livraison des messages. |
| Faire évoluer une application Socket.IO existante ou utiliser les API et l’écosystème Socket.IO | Socket.IO sur Azure | Vous gardez le modèle de programmation Socket.IO sans utiliser Socket.IO infrastructure de connexion ni adaptateur. |
| Connectez les clients MQTT via WebSocket ou échangez des messages entre les clients MQTT et Web PubSub | Prise en charge du MQTT | Vous pouvez utiliser les bibliothèques clients MQTT et laisser Web PubSub traduire entre MQTT pris en charge et concepts natifs. |
| Ajoutez un chat individuel ou de groupe avec salles, adhésion, commande de messages et historique | Chat Web PubSub | Vous obtenez des API spécifiques au chat et des capacités de chat géré au lieu de les concevoir à partir de primitives de messagerie de bas niveau. |
Comprenez comment les capacités diffèrent
Considérez le Web PubSub de base comme une base flexible en temps réel. Il vous donne des éléments de base tels que des connexions, des utilisateurs, des groupes et des événements. C’est vous qui décidez ce que signifient ces éléments de base dans votre candidature.
Les autres capacités enlèvent du travail pour un besoin plus spécifique :
- Socket.IO sur Azure préserve le modèle de programmation que Socket.IO développeurs connaissent déjà.
- Le support MQTT adapte un sous-ensemble supporté de MQTT en Web PubSub afin que les clients MQTT puissent participer à la messagerie en temps réel.
- Le chat Web PubSub offre un modèle d’application de niveau supérieur pour les salles, les membres, les messages et l’historique.
Ce ne sont pas des noms interchangeables pour la même API. La meilleure option est celle qui correspond aux abstractions que votre application utilise déjà ou devrait autrement construire.
| Area | Web PubSub (service de base) | Socket.IO sur Azure | Prise en charge de MQTT | Chat Web PubSub |
|---|---|---|---|---|
| Valeur primaire | Blocs de construction flexibles en temps réel | Développement Socket.IO familier sans mise à l’échelle auto-hébergée | Compatibilité client MQTT et interopérabilité des protocoles | Un modèle de chat prêt à l’emploi |
| Surface de programmation | SDKs Web PubSub, sous-protocoles WebSocket, gestionnaires d’événements et API REST | Socket.IO API client et serveur | Paquets MQTT pris en compte et concepts sur WebSocket | API client et serveur de chat |
| Concepts d’application principaux | Connexions, utilisateurs, groupes et événements | Sockets, salles, espaces de noms et événements | Clients, sujets, abonnements et messages | Utilisateurs, salles, membres, messages et historique |
| Azure handles | Cycle de vie de connexion, mise à l’échelle, routage et diffusion des messages | Hébergement de connexions, scaling et coordination entre serveurs d’applications | Traduction entre les concepts pris en charge de MQTT et Web PubSub | Livraison en temps réel, dispersion, abonnement à la chambre, commande de messages et persistance |
| Vous concevez | Modèle d’événement, charges utiles, flux d’autorisation, logique métier et toute persistance | Événements applicatifs et logique métier | Conception thématique, logique métier et capacités en dehors du sous-ensemble MQTT supporté | Expérience du chat, identités d’applications, attributions d’autorisation et logique métier |
| Meilleur ajustement | Charges de travail personnalisées ou mixtes en temps réel | Applications Socket.IO nouvelles ou existantes | Des clients web utilisant des bibliothèques MQTT ou des clients mixtes MQTT et Web PubSub | Applications où le chat est une fonctionnalité du produit |
Web PubSub (service de base)
Choisissez le Web PubSub de base lorsque la flexibilité est plus précieuse qu’un modèle applicatif conçu spécifiquement. Il offre un transport et un routage en temps réel gérés tout en laissant votre modèle d’événements et votre comportement commercial sous votre contrôle.
Par exemple, votre demande peut :
- Envoyez une mise à jour à tous les clients connectés, un groupe, un utilisateur ou une connexion.
- Recevoir les événements clients dans un serveur d’applications ou Azure Functions.
- Permettre aux clients autorisés de publier des messages directement à un groupe.
- Utilisez des charges utiles et des événements personnalisés pour les flux de travail spécifiques à chaque application.
Cette flexibilité est utile pour les tableaux de bord en direct, la coordination multijoueur, les notifications, les expériences collaboratives, les mises à jour des appareils, la signalisation et le streaming de jetons par IA. Vous évitez d’exploiter des serveurs WebSocket, mais vous continuez à concevoir des fonctionnalités de domaine telles que la persistance des messages, l’historique ou l’adhésion au chat lorsque votre application en a besoin.
Socket.IO sur Azure
Choisissez Socket.IO sur Azure lorsque votre équipe utilise déjà Socket.IO ou souhaite ses API et son écosystème événementiels.
Dans une application Socket.IO auto-hébergée, votre équipe doit maintenir des connexions clients avec état et coordonner plusieurs serveurs Socket.IO en utilisant un adaptateur. Socket.IO on Azure gère l’infrastructure de connexion et la coordination des serveurs. Cette gestion permet à vos serveurs applicatifs de se concentrer sur la gestion des événements et la logique métier.
La valeur clé est la continuité : vous pouvez conserver le modèle de programmation Socket.IO et migrer une application existante avec seulement des modifications limitées de code au lieu de la repenser autour d’une API temps réel différente.
Pour en savoir plus, consultez la section Aperçu Socket.IO sur Azure.
Prise en charge de MQTT
Choisissez la prise en charge MQTT lorsque les clients utilisent des bibliothèques MQTT et se connectent via WebSocket, ou lorsque les clients MQTT doivent échanger des messages avec des clients Web PubSub natifs.
Web PubSub reconnaît les messages MQTT pris en charge et associe les concepts MQTT, tels que les sujets et les abonnements, aux concepts Web PubSub. Cette cartographie vous évite de construire et d’exploiter une couche de traduction protocolaire distincte.
Le support MQTT dans Web PubSub est une adaptation légère, pas un courtier MQTT complet. Il ne prend en charge que les fonctionnalités MQTT qui correspondent à Web PubSub. Des fonctionnalités telles que les abonnements à wildcard, les messages retenus, les abonnements partagés et les alias de sujet ne sont pas prises en charge.
Si votre solution nécessite un courtier MQTT complet, envisagez le support MQTT dans Azure Event Grid. Pour les scénarios Web PubSub pris en charge et les détails du protocole, voir MQTT dans le service Azure Web PubSub.
Chat Web PubSub
Choisissez le chat Web PubSub lorsque le chat est une fonctionnalité du produit et que vous souhaitez consacrer du temps de développement à l’expérience utilisateur plutôt qu’à créer le modèle de chat sous-jacent.
En utilisant Web PubSub de base, vous pouvez créer un chat personnalisé, mais votre équipe définit les charges utiles des messages et prend en compte des préoccupations telles que les salles, l’adhésion, l’ordre des messages et l’historique. Le chat Web PubSub propose ces concepts via des API et SDK conçus spécifiquement.
Le chat Web PubSub est une capacité de niveau supérieur construite sur l’infrastructure en temps réel de Web PubSub. Il offre :
- Un à un et en discussion de groupe.
- Chambres et gestion des membres.
- Messages en temps réel commandés.
- Persistance des messages et historique de la salle.
- Rôles et permissions pour les opérations de chat.
Vous continuez à gérer l’identité de votre application, l’intégration de l’expérience utilisateur et les règles métier, tandis que le service gère l’infrastructure de chat commune.
Pour en savoir plus, consultez Qu’est-ce que le chat Web PubSub ?
Fais le choix
Utilisez ces questions pour réduire la décision :
- Faut-il préserver Socket.IO API ou migrer une application Socket.IO ? Choisissez Socket.IO sur Azure.
- Vos clients doivent-ils communiquer en utilisant le protocole MQTT pris en charge via WebSocket ? Choisissez le support MQTT.
- Avez-vous besoin de salles intégrées, de membres, de commande de messages et d’historique des messages pour une expérience de chat ? Choisissez le chat Web PubSub.
- Avez-vous besoin d’un modèle d’événement personnalisé ou d’un scénario en temps réel qui ne correspond pas aux options précédentes ? Choisissez Web PubSub (service de base).
Choisir une capacité plus spécialisée peut réduire le temps de développement car Azure fournit davantage de modèles applicatifs. Choisir le service de base vous donne plus de contrôle lorsque vos besoins sont uniques. Commencez par la capacité la plus avancée qui répond à vos besoins, et utilisez le service de base lorsque cette flexibilité crée de la valeur pour votre application.