JSの仕組み：Webプッシュ通知

本日、WebテクノロジーとJavaScriptの使用に関する一連の記事の第9部の翻訳を公開します。 この記事では、Webプッシュ通知について説明します。 つまり、それらの基礎となるメカニズム、および通知のサブスクリプションが実行される方法、通知の送受信プロセスがどのように配置されるかについて説明します。







多くの開発者が使用したい機能の1つですが、モバイルアプリケーションの世界では非常に一般的なプッシュ通知がかなり遅れてWebに届きました。

復習

ここで説明しているテクノロジーを使用すると、ユーザーは、新しい素材の出現、または興味のあるイベントの発生についてサブスクライバーに通知することを目的としたWebアプリケーションの定期的な通知をサブスクライブできます。 Webリソース自体の観点から、これは、プッシュ通知にサブスクライブするユーザーをこのリソースにアクセスするよう招待する理由と機会があることを意味します。



プッシュ通知を提供するメカニズムの1つは、 サービスワーカーです。 プッシュ通知を処理するサービスワーカーは、特定のサービスワーカーが担当する新しい通知がブラウザに到着したときにのみコードが実行されるため、システムリソースを経済的に消費します。

プッシュAPIと通知API

ここで「Webプッシュ通知」と呼ぶものは、実際には2つのテクノロジーで表されます。 これは、サーバーがService Workerにメッセージを送信するときに使用されるPush APIと、Service WorkerまたはWebアプリケーション自体のスクリプトがユーザーに通知を表示するときに使用されるNotifications APIです。

プッシュAPI

プッシュ通知メカニズムを実装するには、次の3つの手順を実行する必要があります。

• ユーザーインターフェイスの準備。 このステップでは、ユーザーが通知をサブスクライブできるメカニズムを準備します。
  
  
• プッシュメッセージを送信します。 このステップでは、Webアプリケーション開発者のサーバーで、対応するAPIにアクセスします。これにより、ユーザーのデバイスに通知が送信されます。
  
  
• プッシュメッセージを受信します。 このステップでは、プッシュメッセージはブラウザに配信された後に処理されます。
  
  

これをすべて詳細に検討してください。

ブラウザの機能を確認する

まず、現在のブラウザがプッシュ通知をサポートしているかどうかを確認する必要があります。 これは、次のチェックを実行することで実行できます。

• navigator
  
  
  
  オブジェクトでserviceWorker
  
  
  
  を確認します。
• window
  
  
  
  オブジェクト内のPushManager
  
  
  
  の存在を確認します。

これは次のようなものです。

 if (!('serviceWorker' in navigator)) { //    -. return; } if (!('PushManager' in window)) { //    push-. return; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ユーザーのブラウザーがWebプッシュ通知の操作に必要なテクノロジーをサポートしていない場合、ユーザーにそれらのサブスクライブを申し出ても意味がありません。

サービスワーカー登録

ブラウザを確認した後、必要なものをサポートしていることが判明した場合は、Service Workerの登録に進むことができます。 これを行う方法についてはすでに説明しました。

ユーザー許可の取得

Service Workerの登録後、ユーザーを通知にサブスクライブするプロセスを開始できます。 これを行うには、ユーザーからプッシュメッセージを送信する許可を取得する必要があります。



許可APIは比較的単純です。 注意する必要があるのは、 このAPIの 2つのバージョンが使用されることだけです。



以前のバージョンでは、コールバック関数を受け入れていましたが、現在ではプロミスを返します。 現在のブラウザに実装されているAPIのバージョンを事前に知ることはできないため、これが問題の原因です。 したがって、これらのアプローチの両方をサポートする必要があります。



次のようになります。

 function requestPermission() { return new Promise(function(resolve, reject) {   const permissionResult = Notification.requestPermission(function(result) {     //       .     resolve(result);   });   if (permissionResult) {     permissionResult.then(resolve, reject);   } }) .then(function(permissionResult) {   if (permissionResult !== 'granted') {     throw new Error('Permission not granted.');   } }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Notification.requestPermission()



を呼び出すと、次のウィンドウが表示されます。









通知を表示する許可をリクエストする



ユーザーがAllow



ボタンをクリックしてBlock



するか、ウィンドウを閉じることで許可リクエストに応答すると、結果が行として取得されます。ユーザーの選択に応じて、 'granted'



、 'denied'



、または'default'



。



ユーザーが[ Block



]ボタンをクリックすると、アプリケーションは、通知を表示する許可を個別に「ロック解除」するまでユーザーに要求できなくなります。 これを行うには、ユーザーはブラウザの設定を詳しく調べる必要があります。

PushManagerを使用したユーザーサブスクリプション

サービスワーカーを登録し、通知を表示するユーザー許可を受け取る可能性を確信した後、サービスワーカーのregistration.pushManager.subscribe()



メソッドを呼び出すことでサブスクライブできます。



サービスワーカーの登録を含む、すべての外観は次のとおりです。

 function subscribeUserToPush() { return navigator.serviceWorker.register('service-worker.js') .then(function(registration) {   var subscribeOptions = {     userVisibleOnly: true,     applicationServerKey: btoa(       'BEl62iUYgUivxIkv69yViEuiBIa-Ib9-SkvMeAtA3LFgDzkrxZJjSgSnfckjBJuBkr3qBUYIHBQFLXYp5Nksh8U'     )   };   return registration.pushManager.subscribe(subscribeOptions); }) .then(function(pushSubscription) {   console.log('PushSubscription: ', JSON.stringify(pushSubscription));   return pushSubscription; }); }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

registration.pushManager.subscribe(options)



メソッドは、いくつかのパラメーターを含むoptions



オブジェクトを受け入れます。そのいくつかはオプションです。

• userVisibleOnly
  
  
  
  。 この論理値は、生成されたサブスクリプションがメッセージの表示のみに使用されることを示します。 このパラメーターはtrue
  
  
  
  に設定する必要があります。設定しないとエラーが発生します（これには歴史的な理由があります）。
• applicationServerKey
  
  
  
  。 これは、Base64でエンコードされたDOMString
  
  
  
  、またはプッシュサーバーがアプリケーションサーバーの認証に使用する公開キーを含むArrayBuffer
  
  
  
  オブジェクトです。

Webアプリケーションサーバーは、サーバーに固有のアプリケーションキーのペアを生成する必要があります（VAPIDキーとも呼ばれます）。 このペアには公開鍵と秘密鍵が含まれます。 サーバーは秘密鍵を秘密に保ち、公開鍵をクライアントに転送します。 キーにより、プッシュ通知サービスは、どのアプリケーションサーバーがユーザーにサインアップしたかを認識し、特定のユーザーに通知を送信するサーバーと同じサーバーであることを確認できます。



アプリケーションのキーペアは、一度だけ作成する必要があります。 キーを生成するには、 こちらをご覧ください 。



ブラウザーは、サブスクリプションプロセス中にapplicationServerKey



（公開キー）をプッシュサービスに渡します。 これは、プッシュサービスがアプリケーションの公開キーをサブスクリプションPushSubscription



に関連付けることができることを意味します。



ここで何が起こるかです：

• Webアプリケーションは、サーバーキーを渡してsubscribe()
  
  
  
  ロードして呼び出します。
  
  
• ブラウザーは、プッシュサービスに対してネットワーク要求を行います。プッシュサービスは、独自のAPIへのエントリポイントのアドレスを生成し、このアドレスをキーに関連付けて、ブラウザーに関する情報を返します。
  
  
• ブラウザは、この情報をPushSubscription
  
  
  
  オブジェクトに追加します。このオブジェクトは、 subscribe()
  
  
  
  promiseを通じて返されます。
  
  

後で、プッシュ通知を送信する場合、アプリケーションのプライベートサーバーキーで署名された情報を含むAuthorization



ヘッダーを作成する必要があります。 プッシュサービスが通知を送信する要求を受信すると、上記のプロセスの2番目のステップでAPIエントリポイントに既に関連付けられている公開キーを使用してヘッダーを確認します。

PushSubscriptionオブジェクト

PushSubscription



オブジェクトには、ユーザーのデバイスにプッシュ通知を送信するために必要なすべての情報が含まれています。 これは次のようなものです。

 { "endpoint": "https://domain.pushservice.com/some-id", "keys": {   "p256dh": "BIPUL12DLfytvTajnryr3PJdAgXS3HGMlLqndGcJGabyhHheJYlNGCeXl1dn18gSJ1WArAPIxr4gK0_dQds4yiI=",   "auth":"FPssMOQPmLmXWmdSTdbKVw==" } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

endpoint



プロパティは、プッシュ通知サービスURL、APIへのエントリポイントです。 通知を送信するには、このURLでPOSTリクエストを実行する必要があります。



keys



オブジェクトには、プッシュ通知で送信されるメッセージデータの暗号化に使用される情報が含まれています。



ユーザーが通知をサブスクライブし、 PushSubscription



オブジェクトがある場合、それをサーバーに送信する必要があります。 サーバーでは、このオブジェクトの内容は、たとえばデータベースに保存する必要があり、今後はこの情報を使用して、プッシュ通知を対応するユーザーに送信できます。









許可を取得し、PushSubscriptionオブジェクトを作成してサーバーに送信する

プッシュメッセージを送信する

ユーザーにプッシュメッセージを送信する場合、送信するデータ、送信先、メッセージに関する追加情報について、プッシュサービスに（適切なAPIメソッドを呼び出して）通知する必要があります。 この呼び出しは通常、Webアプリケーションサーバーから行われます。

プッシュサービス

プッシュサービスは、プッシュ通知を送信する要求を受信し、それらをチェックして、適切なブラウザーに通知を配信するシステムです。



プッシュサービスは、Webアプリケーション開発者が管理していないサードパーティのサービスであることに注意してください。 サーバーは、APIを介してプッシュサービスとやり取りするサーバーです。 プッシュサービスの例はGoogle FCMです。



プッシュサービスは、多くの複雑なタスクを処理します。 たとえば、ブラウザがオフラインの場合、プッシュサービスはメッセージをキューに入れ、メッセージが送信されるまでメッセージが送信されるまで待機します。



各ブラウザーは任意のプッシュサービスを使用できますが、Webアプリケーション開発者はプッシュサービスの選択に影響しません。 ただし、すべてのプッシュサービスは同じAPIを使用しているため、これらのサービスの多様性によってプッシュ通知メカニズムの実装に問題が生じることはありません。 プッシュメッセージを送信する要求を処理するURLを取得するには、 PushSubscription



オブジェクトのendpoint



パラメーターの以前に保存された値を参照する必要があります。

プッシュサービスAPI

プッシュサービスAPIは、ユーザーにメッセージを送信するためのツールを提供します。 これは、 Web Push Protocolで表されます。これは、プッシュサービスを操作する手順を定義するIETF標準です。



プッシュメッセージで送信されるデータは暗号化する必要があります。 そのため、開発者はプッシュサービスがユーザーに送信されたデータを表示することを許可しません。 使用するプッシュサービスを決定するのはブラウザーであるため、これは重要です（プッシュサービスが十分に安全でない可能性があります）。



次のプロパティは、プッシュメッセージごとに設定されます。

• TTL
  
  
  
  未配信のプッシュ通知が削除される前にキューで費やすことができる期間を決定します。
  
  
• Priority
  
  
  
  -メッセージの優先度を設定します。これにより、ユーザーのデバイスのバッテリー電力を節約する必要がある場合に、プッシュサービスは優先度の高いメッセージのみを送信できます。
  
  
• Topic
  
  
  
  -プッシュ通知にトピック名を割り当てます。これにより、同じトピックで配信を待機しているメッセージが置き換えられます。 その結果、ユーザーのデバイスがアクティブになるとすぐに、ユーザーは最新のメッセージを受け取ります。
  
  

Webアプリケーション開発者サーバー、プッシュサーバー、およびメッセージの到着先のブラウザー

ブラウザプッシュイベント

メッセージがプッシュサービスに送信されるとすぐに、次のいずれかのイベントが発生するまで待機状態になります。

• デバイスはオンラインです。
  
  
• TTLパラメーターで指定されたメッセージ保持時間が切れました。
  
  

プッシュサービスがメッセージを配信すると、ブラウザーはそれを受信し、解読し、以前に登録されたサービスワーカーでプッシュイベントをトリガーします。



最も興味深いのは、対応するWebページが開いていなくても、ブラウザーがサービスワーカーを呼び出すことができることです。 ここで次のことが起こります。

• プッシュ通知がブラウザに届き、ブラウザはそれを解読します。
  
  
• ブラウザはService Workerをアクティブにします。
  
  
• プッシュイベントはサービスワーカーにディスパッチされます。
  
  

プッシュイベントハンドラーの構成に使用されるコードは、他のJavaScriptイベントハンドラーのコードのように見えます。

 self.addEventListener('push', function(event) { if (event.data) {   console.log('This push event has data: ', event.data.text()); } else {   console.log('This push event has no data.'); } });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サービスワーカーの機能について説明する場合、サービスワーカーをアクティブにするタイミングと停止するタイミングを決定するのはブラウザーであるため、開発者はサービスワーカーの実行時間を最小限のレベルで制御できることに注意してください。



サービスワーカーevent.waitUntil(promise)



の構築は、 event.waitUntil(promise)



解決する前に、サービスワーカーが通知の処理でビジーであり、ブラウザーがこの作業が完了する前にサービスワーカーをシャットダウンしてはならないことをブラウザに伝えます。



プッシュイベントを処理するためのサンプルコードを次に示します。

 self.addEventListener('push', function(event) { var promise = self.registration.showNotification('Push notification!'); event.waitUntil(promise); });
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

self.registration.showNotification()



呼び出しは、ユーザーが見ることができる通知を導きます。この呼び出しは、通知が表示されるとすぐに解決される約束を返します。



showNotification(title, options)



メソッドを使用すると、開発者のニーズに応じて通知の外観をカスタマイズできます。 したがって、 title



パラメーターは文字列であり、 options



パラメーターは次の内容のオブジェクトです。

 { "//": "Visual Options", "body": "<String>", "icon": "<URL String>", "image": "<URL String>", "badge": "<URL String>", "vibrate": "<Array of Integers>", "sound": "<URL String>", "dir": "<String of 'auto' | 'ltr' | 'rtl'>", "//": "Behavioural Options", "tag": "<String>", "data": "<Anything>", "requireInteraction": "<boolean>", "renotify": "<Boolean>", "silent": "<Boolean>", "//": "Both Visual & Behavioural Options", "actions": "<Array of Strings>", "//": "Information Option. No visual affect.", "timestamp": "<Long>" }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、通知の外観のカスタマイズについて詳しく読むことができます。

まとめ

プッシュ通知は、使用されるリソースとこれらのリソースのユーザーの両方に利益をもたらすことができます。 おそらく、Webリソースの所有者が覚えておくべき主なことは、プッシュ通知にはユーザーにとって本当に興味深く必要なものが含まれていることです。



この記事の著者は、彼の会社であるSessionStackは 、プッシュ通知を使用して、プロジェクトのクラッシュ、問題、または異常をユーザーに通知することを計画していると述べています。 これにより、緊急事態について即座に学習し、適切な対策を講じることができます。



一連の記事の前の部分：



パート1： JSの仕組み：エンジン、ランタイムメカニズム、コールスタックの概要

パート2： JSの仕組み：V8内部とコードの最適化について

パート3： JSの仕組み：メモリ管理、4種類のメモリリーク、およびそれらとの戦い

パート4： JSの仕組み：イベントループ、非同期、およびasync / awaitを使用してコードを改善する5つの方法

パート5： JSの仕組み：WebSocketとHTTP / 2 + SSE。 何を選ぶ？

パート6： JSの仕組み：WebAssemblyの機能と範囲

パート7： JSの仕組み：Web Workersと5つの使用シナリオ

パート8： JSの仕組み：サービスワーカー



親愛なる読者！ プロジェクトでプッシュ通知を使用していますか？