Lors de son récent événement Ignite, Microsoft a dévoilé une nouvelle application Office : Boucle. Construit sur sa plate-forme de collaboration Fluid Framework en temps réel promise depuis longtemps, Loop est un canevas qui héberge des composants pour le travail partagé, offrant un endroit pour garder ensemble tous les différents éléments du projet d’une équipe.
Vous pourriez considérer Loop comme le successeur spirituel du travail de l’ancien architecte logiciel en chef de Microsoft Ray Ozzie sur Notes et Groove. Loop mélange des documents, des outils d’édition et des conversations afin qu’une équipe puisse créer des documents tout en gérant les discussions autour du contenu. Il s’appuie sur les concepts de micro-travail que nous voyons dans des outils tels que Teams, décomposant les unités de travail et de collaboration en composants pouvant être insérés dans des documents Loop.
Microsoft Loop est fluide
Le modèle de composant de Loop utilise Fluid Framework pour construire des composants, soit en tant qu’outils de boucle autonomes, soit en tant qu’éléments d’une autre application. Il est possible de voir des outils collaboratifs Office tels que OneNote devenir des collections de composants de boucle, tandis que la plate-forme Power pourrait fournir des points de terminaison de boucle en tant que fin de flux ou en tant que sorties de Power BI ou d’exportations à partir du magasin d’objets Dataverse.
Cependant, Loop n’est qu’une partie de ce que propose le Fluid Framework. Ce n’est pas seulement un outil pour les propres produits de Microsoft, c’est un moyen de créer vos propres outils de collaboration ou de fournir des données en temps réel aux bureaux de vos utilisateurs. Vous pouvez utiliser Fluid Framework comme alternative aux technologies telles que SignalR pour partager l’état entre plusieurs points de terminaison. Cette dernière partie est peut-être l’aspect le plus important de Fluid, car il s’agit d’un framework de calcul distribué plusieurs-à-plusieurs, à faible latence.
Le partage de l’état entre de nombreux points de terminaison différents n’est pas facile ; le faire en temps réel est encore plus difficile. La plupart des alternatives sont des systèmes un-à-un ou un-à-plusieurs – ils ne gèrent pas l’état de dizaines d’utilisateurs, et peut-être autant d’applications différentes. Je peux utiliser Loop pour créer un document collaboratif avec vous, mais vous pouvez produire des données dont nous avons besoin dans Power BI, Word, Lists ou tout autre outil Microsoft 365 compatible Fluid.
Relaying Fluid state avec Azure
Un aspect clé de l’architecture Fluid Framework est le relais qui se trouve au cœur de toutes les collaborations applicatives. Bien qu’une grande partie du travail soit gérée par les bibliothèques clientes lors de la collecte et de la gestion de l’état, un serveur est toujours nécessaire pour garantir que les données sont fournies correctement et que seuls les clients authentifiés ont accès à votre contenu.
C’est là que le relais fluide Azure< /a> entre en jeu. Au lieu de créer et d’exécuter votre propre serveur pour servir de hub de collaboration, Azure propose une solution gérée prédéfinie qui peut être rapidement déployée et utilisée par votre code côté client avec un travail minimal de votre part. Le workflow reste simple, car l’état est géré par les clients. Tout ce que le serveur a à faire est d’écouter les messages, de les séquencer de manière appropriée, puis de les renvoyer à tous les clients. Le code côté client reconstruit ensuite l’état.
Si vous savez comment une table de journal de base de données peut reconstruire le contenu d’une base de données lorsqu’elle est relue, vous pouvez considérer Fluid Framework comme un service de journal et de relecture de journal distribué. Chaque client enregistre son propre état sur le serveur Fluid, qui agit comme un client syslog distribué, enregistrant le journal agrégé résultant pour tous les clients.
Microsoft a lancé un aperçu du service Azure Fluid Relay avec un ensemble associé de bibliothèques clientes Azure. Cela doit correspondre à la version actuelle des composants Fluid Framework, afin que votre code puisse fonctionner avec le vôtre et les services Azure.
Configuration d’Azure Fluid Relay
Pour utiliser le service, commencez par créer un Fluid Relay dans un groupe de ressources Azure. Le prix est gratuit pendant l’aperçu, sans date encore pour le passage de l’aperçu à la disponibilité générale. Comme la plupart des aperçus Azure, il s’agit de uniquement disponible dans un ensemble limité de régions, vous devrez donc peut-être prendre en compte la latence du réseau si vous travaillez en dehors de l’ouest d’Azure US, Ouest Europe ou les régions d’Asie du Sud-Est. Il n’y a pas d’accord de niveau de service pendant la préversion, utilisez donc le service pour l’expérimentation et le développement car il n’est pas adapté au code de production.
La configuration d’un relais se fait en quelques clics et en attendant que le service se déploie. Une fois déployé, vous pouvez accéder au SI et aux clés nécessaires aux applications clientes pour se connecter à votre relais. J’ai écrit sur la création d’applications Fluid dans une colonne précédente, et il y a peu de différence entre l’exécution sur un serveur de développement local et l’utilisation d’Azure. Votre tâche principale lors du portage du code existant vers le service consistera à ajouter un ID de locataire, une instance ITokenProvider qui utilise la clé primaire du service Azure et des URL pour les services de commande et de stockage.
Microsoft fournit un exemple de code sous la forme d’une fonction Azure qui empêche vos clés d’apparaître dans le code client. À l’aide de cet outil, vous pouvez ajouter les détails de l’utilisateur au jeton généré, ce qui vous permet de suivre plus en détail l’utilisation de votre service. En travaillant avec les bibliothèques clientes Azure, vous pouvez créer des conteneurs pour les données de votre service, en fournissant un schéma pour les messages que votre service relayera.
Travailler avec Azure Fluid Relay
Chaque conteneur est peut-être mieux considéré comme une définition de l’espace de collaboration qui est mis en œuvre dans les documents sur chaque client. Le conteneur est l’hôte du des structures de données distribuées qui contiennent l’état de votre application. Le code adresse les points de terminaison du conteneur dans le relais, en modifiant le contenu dans une structure de données. Vous devez considérer comment votre code prend en charge à la fois la simultanéité et la cohérence, car vous travaillez dans un environnement informatique distribué avec une faible latence. Cela rend les écritures simultanées un risque, vous devez donc choisir une méthode appropriée de gestion des fusions.
Cette approche vous permet de créer un environnement Fluid personnalisé pour votre application où le conteneur décrit votre propre modèle de document spécifique, au-delà de ces offres Microsoft. Il est associé à un objet de services utilisé pour suivre les utilisateurs travaillant actuellement avec le service. Votre code peut utiliser les bibliothèques clientes pour obtenir des données utilisateur à partir de l’objet de service, en les affichant sous forme de liste en direct dans votre canevas. Les événements sont déclenchés lorsque les utilisateurs entrent ou sortent du conteneur Fluid, vous donnant une vue en temps réel des utilisateurs à côté du contenu en temps réel.
Une option intéressante pour Fluid utilisant Azure est déployer votre code en tant qu’applications Web statiques Azure, en les intégrant dans votre workflow git. Une application Web Jamstack agit comme une interface pour Azure Functions qui gère l’authentification, avec JavaScript côté client se connectant à votre Fluid Relay.
Le Fluid Framework est une approche fascinante pour fournir des applications collaboratives et distribuées. Le déplacement d’une grande partie des fonctionnalités vers les clients réduit considérablement la complexité. Par conséquent, l’utilisation d’un serveur hébergé pour gérer et rassembler vos données vous permet de vous concentrer sur la fourniture de la meilleure application possible à vos utilisateurs. Microsoft a l’intention de garder le le serveur, les bibliothèques clientes et le protocole sont synchronisés, donc si vous devez passer à un serveur Fluid privé, le même code peut être utilisé ; tout ce que vous avez à faire est de changer les points de terminaison.
Pour les applications publiques utilisant Azure, il s’agit d’une solution judicieuse, en particulier lorsqu’elle est utilisée avec des outils tels que les applications et fonctions Web statiques. La seule question est de savoir combien cela coûtera lorsqu’il sortira de l’aperçu. S’il est comparable aux autres services de messagerie Azure de Microsoft, tels que Event Grid, vous devriez envisager moins d’un dollar pour un million d’opérations.
.
Toute l’actualité en temps réel, est sur L’Entrepreneur
