Fonctionnement du transfert

Avant d'aborder l'API, intéressons-nous au transfert de façon globale, du début à la fin. Ensuite, au fur et à mesure que nous examinerons des sujets individuels ou des API, vous aurez une idée de comment et pourquoi c'est important.

Voici les trois étapes clés à suivre pour implémenter la méthode push:

  1. Ajouter la logique côté client pour abonner un utilisateur aux notifications push (c'est-à-dire le code JavaScript et l'UI de votre application Web qui enregistre un utilisateur pour envoyer des messages)
  2. Appel d'API à partir de votre backend ou de votre application qui déclenche un message push sur l'appareil d'un utilisateur.
  3. Fichier JavaScript du service worker qui recevra un "événement push" à sa réception sur l'appareil. C'est dans ce JavaScript que vous pourrez afficher une notification.

Voyons plus en détail ce qu'implique chacune de ces étapes.

Étape 1: Côté client

La première étape consiste à "abonner" un utilisateur pour envoyer des messages push.

Deux éléments sont nécessaires pour s'abonner à un utilisateur. Tout d'abord, vous devez obtenir l'autorisation de l'utilisateur pour lui envoyer des messages push. Deuxièmement, obtenir un PushSubscription à partir du navigateur.

PushSubscription contient toutes les informations dont nous avons besoin pour envoyer un message push à cet utilisateur. Vous pouvez considérer cela comme un identifiant pour l'appareil de cet utilisateur.

Tout cela se fait en JavaScript avec l'API Push.

Navigateurs pris en charge

  • 42
  • 17
  • 44
  • 16

Source

Avant d'abonner un utilisateur, vous devez générer un ensemble de "clés de serveur d'applications". Nous en parlerons plus tard.

Les clés du serveur d'applications, également appelées clés VAPID, sont propres à votre serveur. Elles permettent à un service push de savoir quel serveur d'applications a abonné un utilisateur et de s'assurer que c'est le même serveur qui a déclenché les messages push vers cet utilisateur.

Une fois que vous avez abonné l'utilisateur et que vous disposez d'un PushSubscription, vous devez envoyer les informations PushSubscription à votre backend / serveur. Sur votre serveur, vous allez enregistrer cet abonnement dans une base de données et l'utiliser pour envoyer un message push à cet utilisateur.

Assurez-vous d'envoyer l'abonnement PushSubscription à votre backend.

Étape 2: Envoyez un message push

Lorsque vous souhaitez envoyer un message push à vos utilisateurs, vous devez effectuer un appel d'API vers un service push. Cet appel d'API inclurait quelles données envoyer, à qui envoyer le message et tous les critères relatifs à l'envoi du message. Normalement, cet appel d'API est effectué à partir de votre serveur.

Voici quelques questions que vous pourriez vous poser:

  • Qui et qu'est-ce que le service push ?
  • À quoi ressemble l'API ? Est-ce du format JSON, XML ou autre chose ?
  • À quoi sert l'API ?

Qui et qu'est-ce que le service push ?

Un service push reçoit une requête réseau, la valide et envoie un message push au navigateur approprié. Si le navigateur est hors connexion, le message est mis en file d'attente jusqu'à ce que le navigateur se connecte.

Chaque navigateur peut utiliser n'importe quel service push de son choix. Les développeurs n'ont aucun contrôle sur ce service. Ce n'est pas un problème, car chaque service push attend le même appel d'API. Autrement dit, vous n'avez pas à vous soucier de l'identité du service push. Il vous suffit de vous assurer que votre appel d'API est valide.

Pour obtenir l'URL appropriée afin de déclencher un message push (c'est-à-dire l'URL du service push), il vous suffit de consulter la valeur endpoint dans un PushSubscription.

Voici un exemple des valeurs que vous recevez d'un PushSubscription:

{
  "endpoint": "https://random-push-service.com/some-kind-of-unique-id-1234/v2/",
  "keys": {
    "p256dh": "BNcRdreALRFXTkOOUHK1EtK2wtaz5Ry4YfYCA_0QTpQtUbVlUls0VJXg7A8u-Ts1XbjhazAkj7I99e8QcYP7DkM=",
    "auth": "tBHItJI5svbpez7KI4CCXg=="
  }
}

Dans ce cas, le point de terminaison est [https://random-push-service.com/some-kind-of-unique-id-1234/v2/]. Le service push serait "random-push-service.com" et chaque point de terminaison est unique à un utilisateur, indiqué par "some-kind-of-unique-id-1234". Lorsque vous commencerez à travailler avec le mode push, vous remarquerez ce schéma.

Les clés de l'abonnement seront abordées plus tard.

À quoi ressemble l'API ?

Comme je l'ai dit, tous les services Web push attendent le même appel d'API. Cette API correspond au protocole Web Push. Il s'agit d'une norme IETF qui définit la façon dont vous effectuez un appel d'API vers un service push.

L'appel d'API nécessite la définition de certains en-têtes et les données sous forme de flux d'octets. Nous allons examiner les bibliothèques pouvant effectuer cet appel d'API à notre place, et nous verrons comment le faire nous-mêmes.

À quoi sert l'API ?

L'API permet d'envoyer un message à un utilisateur, avec ou sans données, et fournit des instructions indiquant comment envoyer le message.

Les données que vous envoyez avec un message push doivent être chiffrées. En effet, cela empêche les services push, qui peuvent être n'importe qui, de voir les données envoyées avec le message push. Ce point est important, car c'est le navigateur qui décide quel service push utiliser, ce qui peut ouvrir la porte aux navigateurs en utilisant un service push qui n'est ni sûr, ni sécurisé.

Lorsque vous déclenchez un message push, le service push reçoit l'appel d'API et met le message en file d'attente. Ce message reste en file d'attente jusqu'à ce que l'appareil de l'utilisateur se connecte et que le service push puisse distribuer les messages. Les instructions que vous pouvez fournir au service push définissent la manière dont le message est mis en file d'attente.

Les instructions incluent des informations telles que:

  • Valeur TTL d'un message push. Ce paramètre définit la durée pendant laquelle un message doit être mis en file d'attente avant d'être supprimé et non distribué.

  • Définissez le degré d'urgence du message. Cela est utile si le service push préserve l'autonomie de la batterie des utilisateurs en ne fournissant que des messages à priorité élevée.

  • Attribuez un nom de "sujet" à un message push qui remplacera tout message en attente par ce nouveau message.

Lorsque votre serveur souhaite envoyer un message push, il envoie une requête de protocole Web push à un service push.

Étape 3: Événement push sur l'appareil de l'utilisateur

Une fois que nous avons envoyé un message push, le service push le conserve sur son serveur jusqu'à ce que l'un des événements suivants se produise:

  1. L'appareil se connecte et le service push distribue le message.
  2. Le message expire. Dans ce cas, le service push supprime le message de sa file d'attente et il ne sera jamais distribué.

Lorsque le service push distribue un message, le navigateur le reçoit, déchiffre toutes les données et envoie un événement push à votre service worker.

Un service worker est un fichier JavaScript "spécial". Le navigateur peut exécuter ce code JavaScript sans que votre page soit ouverte. Il peut même exécuter ce JavaScript lorsque le navigateur est fermé. Un service worker possède également des API, telles que le mode push, qui ne sont pas disponibles sur la page Web (c'est-à-dire des API qui ne le sont pas à partir d'un script de service worker).

C'est dans l'événement "push" du service worker que vous pouvez effectuer n'importe quelle tâche en arrière-plan. Vous pouvez effectuer des appels d'analyse, mettre en cache des pages hors connexion et afficher des notifications.

Lorsqu'un message push est envoyé d'un service push vers l'appareil d'un utilisateur, votre service worker reçoit un événement push.

C'est tout le flux de messages push.

Étapes suivantes

Ateliers de programmation