Utiliser les API de Vonage avec MongoDB Atlas - Partie 5

Dans cette série :

• Partie 1 - Qu'est-ce que MongoDB Atlas ?

• Partie 2 - Utilisation de Vonage Verify avec les ouvertures de session

• Partie 3 - Utilisation de Vonage pour les interactions avec les clients

• Partie 4 - Utilisation d'Atlas pour l'authentification des utilisateurs

• Partie 5 - Utiliser In-App Messaging de Vonage pour les notifications

Nous terminons notre série sur MongoDB Atlas et les API de Vonage avec un regard sur notre In-App Messaging API. Dans les autres parties de la série, nous avons vu comment configurer MongoDB Atlas et Vonage dans la première partie, comment ajouter Vonage Verify à une application dans la deuxième partie, comment permettre l'interaction avec les clients grâce à nos API Messages et Meetings API, et enfin comment utiliser notre API In-App Messaging pour envoyer des notifications aux utilisateurs connectés à la section d'administration de notre site.

In-App Messaging

In-App Messaging fait partie d'un ensemble complet de conversations API, l'autre moitié de l'API étant notre produit In-App Voice. Comme leurs noms l'indiquent, In-App Messaging gère l'envoi de messages textuels d'un appareil client à un autre, tandis que In-App Voice s'occupera du trafic vocal. Ces API disposent de SDK pour iOS, Android et les navigateurs web modernes. Nous présenterons le Client SDK Web pour notre démo, mais vous pouvez l'étendre pour permettre une communication inter-plateforme à partir de n'importe quelle combinaison de Web, iOS et Android.

In-App Messaging et In-App Voice sont pris en charge par deux autres API qui composent notre produit Conversations. Il s'agit de l'API Conversation, qui correspond à des événements entre un ou plusieurs membres, et de l'API Utilisateurs, qui gère les informations relatives au contexte de l'utilisateur. En règle générale, un utilisateur s'authentifie via votre application et est associé à un utilisateur dans notre API Utilisateurs. Cet utilisateur deviendra membre de diverses conversations, ou magasins d'événements composés de différents événements déclenchés tels que text, message:submitted, member:joined, etc.

Chaque Client SDK communiquera avec ces serveurs dorsaux pour faciliter la communication en temps réel par le biais d'événements vocaux ou textuels. En tant que développeur, vous disposez ainsi d'une seule interface pour interagir avec nos API, les SDK se chargeant de tout le travail de connexion et d'utilisation de nos API. Vous n'avez donc pas besoin de concevoir des systèmes de messagerie dépendant de la plateforme ou des moyens de transférer les messages entre différentes plateformes.

Nous utiliserons l'In-App Messaging API pour notre démo de restaurant afin d'envoyer un message à n'importe quel utilisateur administrateur connecté. Une fenêtre contextuelle s'affichera alors sur leur écran avec un lien vers la réunion demandée. Bien que nous l'utilisions pour une simple notification, vous pouvez l'étendre à un système de chat complet. Nous utiliserons l'option nexmo-client pour gérer tout le travail dans le navigateur, et nous utiliserons un client personnalisé dans le code de notre serveur dorsal pour communiquer avec les API de Conversation.

Les notifications de l'administrateur

Commençons par examiner le fonctionnement de la section d'administration. Nous voulons qu'une notification s'affiche lorsqu'un utilisateur demande une réunion. Pour les notifications pop-up, nous pouvons utiliser @meforma/vue-toasterqui est un plugin VueJS qui génère des pop-ups de type toast (les toasts sont de petites notifications qui s'affichent en bas de l'écran et disparaissent ensuite).

Mais comment obtenir la notification ? Nous devons utiliser le nexmo-client pour nous connecter à notre Application Vonage et nous abonner à la conversation ou à la série de messages appropriée. Nous avons créé un composant de notification qui se connectera à la conversation et affichera toutes les nouvelles notifications qui arrivent.

import ConversationClient from 'nexmo-client'
import { createToaster } from '@meforma/vue-toaster'
import { authenticationStore } from '../stores/authenticationStore';

const authStore = authenticationStore();
const toaster = createToaster({ dismissable: true });

async function boot() {
    const data = await fetch(import.meta.env.VITE_API_URL + '/jwt', {
        method: 'POST',
        body: JSON.stringify({username: authStore.username}),
        headers: {
            'Content-Type': 'application/json',
            'Authorization': 'Bearer ' + authStore.token
        }
    })
        .then(resp => resp.json())
        .catch(err => console.log(err));
    
    const jwt = data.token
    const conversationID = data.conversation

    const client = new ConversationClient({ debug: true })
    let app = await client.createSession(jwt)
    const conversation = await app.getConversation(conversationID)

    conversation.on("support_request", async (sender: any, event: any) => {
        toaster.show(`${event.body.email} has request support: <a target="_blank" href="${event.body.host_url}">Join Meeting</a>`);
    });
}

boot()

Nous avons besoin d'un jeton d'autorisation pour connecter le SDK web à Vonage. Ce jeton est un JWT signé à l'aide de la clé privée que nous avons générée dans la partie 1 lorsque nous avons créé une application Vonage. Ce JWT permettra au SDK Web de communiquer avec les API de Vonage et de s'authentifier. C'est à peu près de la même manière que MongoDB Realms a authentifié notre utilisateur administrateur.

Pour obtenir des informations complètes sur la création de JWT client pour l'API Conversations, consultez notre documentation. Nous allons revoir la façon dont nous créons le JWT dans une seconde afin que vous puissiez voir un exemple, mais pour l'instant, continuons avec le code VueJS. Pour l'instant, nous n'avons qu'à nous soucier de demander à notre serveur dorsal de générer un JWT pour nos utilisateurs.

Le serveur dorsal renvoie deux informations : le JWT signé de Vonage et l'identifiant de la conversation à laquelle nous devons nous connecter. Nous en aurons besoin pour indiquer au SDK web quelle conversation écouter.

Ensuite, nous créons un nouvel objet ConversationClient()un objet du paquet nexmo-client paquet. Nous appelons createSession(jwt) sur cet objet et transmettons le JWT que notre backend a créé pour nous. Cela permet d'authentifier notre application web auprès de Vonage. Ensuite, nous lui demandons d'obtenir une conversation spécifique, l'ID que notre serveur dorsal nous a renvoyé.

Notre application est maintenant à l'écoute des événements mais ne gère rien. Nous devons utiliser la méthode conversation.on() pour gérer les messages entrants. Nous utiliserons un message personnalisé appelé support_request pour passer ce nom en tant que premier paramètre. Le second paramètre est une fonction de traitement. Notre fonction de traitement extraira les informations de la demande d'assistance et affichera une notification.

Voilà, c'est fait. Si vous vous connectez à la section d'administration et que vous allez à Voir les commandesvous pouvez voir cela en action. Si vous ouvrez une nouvelle fenêtre, que vous vous connectez en tant que client et que vous envoyez une commande, que vous lancez un appel vidéo, une nouvelle notification devrait apparaître dans la fenêtre d'administration.

Comment avons-nous généré un jeton ?

Avant d'examiner le code du backend, voyons comment nous avons créé le JWT. Nous devons ajouter deux informations cruciales au JWT pour créer un jeton valide côté client. Il s'agit de subqui est l'utilisateur pour lequel le jeton est généré. L'autre est pathune liste de chemins auxquels le JWT peut accéder.

app.post('/jwt', async (req, res) => {
    const { username } = req.body;
    const conversation = await conversations.fetchByName('pos-notifications');
    const conversationPath = `/*/conversations/${conversation.id}/**`;
    let acl = {
        "paths": {
            "/*/sessions/**": {},
          }
    }
    acl.paths[conversationPath] = { methods: ['GET'] }

    const key = readFileSync(process.env.VONAGE_PRIVATE_KEY);
    const token = tokenGenerate(process.env.VONAGE_APPLICATION_ID, key, {
        sub: username,
        acl: acl,
    });
    res.json({ token, conversation: conversation.id })
})

Pour limiter notre jeton à ce dont nous avons besoin, nous définissons notre ACL à /*/sessions/** et /*/conversations/<conversation-id>/**. Cela signifie que notre JWT n'est valide que pour la conversation spécifique à laquelle nos notifications sont envoyées, appelée pos-notifications. Si quelqu'un devait détourner le jeton, il ne permettrait d'accéder qu'à une seule conversation.

Nous sécurisons davantage le JWT en lui indiquant que nous n'autoriserons que les GET à la conversation. Cela signifie que notre interface ou toute personne qui tente d'utiliser le JWT ne pourra que lire la conversation et non la modifier. Dans votre application, vous devez restreindre les chemins et les méthodes pour être aussi strict que possible pour le JWT.

Création d'une notification

Nous savons comment lire dans une conversation, mais comment intégrer un événement dans une conversation ? Si nous ouvrons notre fichier server.ts et que nous nous rendons sur notre route /api/website/video-call nous générons un nouvel événement.

const orderRecord = await client.db('restaurant_pos_demo')
    .collection('orders')
    .updateOne(
        { _id: new ObjectId(orderNumber) },
        { $set: { meetingUrl: data._links.host_url.href}}
    )
    .then(async (document) => {
        const userRecord = await client.db('restaurant_pos_demo')
            .collection('users')
            .findOne({ _id: new ObjectId(decodedToken.user_id) });

        await conversations.addEventToConversation(
            'pos-notifications',
            userRecord.username, 
            {
                type: 'custom:support_request',
                body: { 
                    host_url: data._links.host_url.href,
                    email: userRecord.username
                }
            });

        res.json({
            guest_url: data._links.guest_url.href
        })
    });

Nous mettons à jour l'ordre avec les nouvelles URL de réunion. Une fois cette opération terminée, nous recherchons l'utilisateur dans MongoDB à l'aide de la collection users et findOne(). Cela nous permet d'obtenir l'enregistrement de l'utilisateur authentifié, et nous pouvons alors utiliser conversations.addEventToConversation() pour introduire un nouvel événement dans notre conversation. Pour toutes les notifications, nous utilisons une conversation nommée pos-notifications.

addEventToConversation() est un wrapper qui gère une grande partie du travail sous-jacent nécessaire pour ajouter un événement à une conversation et fait partie d'une collection de méthodes dans conversation.ts qui se chargeront de la recherche et de la configuration pour nous.

Comme je l'ai mentionné précédemment, l'API Conversations est une combinaison des API Conversations et Utilisateurs. Lorsque nous appelons addEventToConversation()la méthode tentera d'extraire une conversation portant le nom spécifié. Cette recherche de conversation générera une conversation avec un nom (dans notre cas, pos-notification) s'il n'en existe pas.

Nous avons ensuite besoin d'un membre auquel rattacher l'événement. Les membres sont des utilisateurs qui font partie d'une conversation spécifique. Un membre ne participe qu'à une seule conversation. Toutefois, un utilisateur peut être membre de plusieurs conversations. addEventToConversation() tentera de rechercher un membre à partir de l'adresse électronique spécifiée. Si ce membre ne fait pas partie de la conversation, nous ajoutons également l'événement. Il recherchera un utilisateur avec cette adresse électronique. Si cet utilisateur n'existe pas, il est créé. Cet utilisateur est alors ajouté à la conversation en tant que membre, et les informations relatives au membre sont renvoyées.

Nous pouvons alors intégrer le nouvel événement dans la conversation. L'événement est propagé à tous les clients connectés qui écoutent la conversation. Lorsque nous soumettons un événement sur le serveur, tous les utilisateurs connectés à la page "Commandes" recevront l'événement et la notification contextuelle.

Conclusion

Il s'agit là d'un tout petit aperçu des possibilités offertes par la Conversation API. Vous pouvez créer des interfaces de discussion dotées de toutes les fonctionnalités attendues par les utilisateurs, telles que les notifications de saisie, le partage d'images et le stockage des messages. De plus, tout cela se fait en temps réel et sur plusieurs plateformes. Un utilisateur web peut envoyer une notification à un client iOS de la même manière qu'à un client Android ou à un autre client web.

Vous pouvez également coupler cela avec In-App Voice pour fournir une voix en temps réel entre plusieurs clients ou combiner cela avec notre Voice API pour permettre à un utilisateur d'application d'appeler un téléphone ou vice versa. Le client pourrait ainsi appeler le restaurant et ce dernier pourrait lui répondre dans son navigateur !

Ceci termine notre visite de MongoDB Atlas et de quelques API complémentaires de Vonage. Nous espérons que cette série vous a incité à voir ce que chacune de nos plateformes offre et comment elles pourraient vous être utiles. Comme toujours, contactez nos développeurs si vous avez des questions.

Bon codage !

• Partie 1 - Qu'est-ce que MongoDB Atlas ?

• Partie 2 - Utilisation de Vonage Verify avec les ouvertures de session

• Partie 3 - Utilisation de Vonage pour les interactions avec les clients

• Partie 4 - Utilisation d'Atlas pour l'authentification des utilisateurs

• Partie 5 - Utiliser In-App Messaging de Vonage pour les notifications