2024.05.06

Pusherのリアルタイム通信機能「Channels」を試してみる

nantacon

下記記事で、WebSocketを用いたソフトウェアフレームワークについて調べた。PusherというSaaSのサービスを用いると、マルチクライアント接続がWebSocketベースの通信が簡単に実現できるらしいので、今回実際に試してみようと思う。

リモートデバイス/ロボットを遠隔操作するプロトコルやソフトウェアフレームワークを調べてみた

Contents

Pusherとは
Pusherのチュートリアルに従って試してみる
ServerとClientの違いについて
- Pusherでは、全てのクライアントが双方向通信できるのではないか？そうするとサーバーとクライアントの違いは何か？
- 結論：双方向通信する場合、各ノードはServer APIとClient APIの両方を使うことになる
双方向通信を実現する場合のプログラミング上の制約
Pusher使用例
まとめ

Pusherとは

Pusherはリアルタイム機能をクラウドベースで提供するサービスで、WebSocketと同様のAPIを通じてリアルタイム通信を提供する。

APIを通じてリアルタイムメッセージングや通知、ブロードキャストが可能で、開発者はサーバーの管理やスケーリングを心配する必要がない。

Socket.ioのようなことがSaaSで実現でき、ユーザは楽に双方向のリアルタイム通信を実現できる。

Pusherには「Channels」と「Beams」の２種類の製品がある。Channelsはリアルタイム通信のサービス、Beamsはプッシュ通知のサービス。今回はChannelsを使う。

料金表はこちらにある。お試しで使うならSandBoxプランで無料で使える。

Pusherのチュートリアルに従って試してみる

早速、Pusherを使っていこうと思う。

PusherのWebサイトに行き、ユーザ登録

PusherはSaaSなので、まずWebサイトに行き、ユーザ登録を行う必要がある。

PusherのWebサイトはこちら。

アクセスしたら、右上のSign UpからGithubかGoogleアカウントを登録し、使えるようにする。

アプリ登録

Pusherへのユーザ登録が済むと、「Welcome to Pusher」のページに着く。

ChannelsかBeamsかを選択するように言われるので、Channelsの方のGet Startedを選択する。

Channelsを選ぶと、アプリ登録の画面になるので、必要な情報を入力し、Create appを押下。

Name your app : アプリ名。後で変更可能。
Select a cluster : クラスタの選択。デフォルトでap3(東京)が出てくるのでそのまま。
Create apps for multiple environment: ステージングと本番の環境を分けるなどしたい場合は、チェックを入れる。今回はチェックを外した。
Choose your tech stack(任意)：フロントエンドとバックエンドの言語を指定。今回はフロントエンドをReactに、バックエンドをpythonにした。これはただ次のページに出てくるコードの使用例を表示するときの設定なので、あまり重要ではない。

Getting Startedのガイドに従って使ってみる

Create Appを経た後、Getting Startedのページに飛ばされる。

超シンプルで、STEP1とSTEP2しか書いていない。

STEP1には、「クライアント側でイベントを購読する方法とコード」が載っている
STEP2には、「サーバー側からイベントを発行する方法とコード」が載っている

一旦、STEP1とSTEP2のコードを手元のパソコンにダウンロードして、実行してみようと思う。

STEP1

自分の場合、STEP1の方にはJavascriptコードが埋め込まれたhtmlのコードが表示されていた。my-channelというチャンネルを購読し、my-eventというイベントを拾って表示する。

右上のDownloadボタンをクリックし、index.htmlとして保存。ブラウザで開くと、下記のような表示が出る。Serverからイベントが発行されると、alert関数によりメッセージがポップアップ表示される仕様のようだ。

STEP2

次にSTEP2側を確認してみる。こちらはPythonのコードで、イベントを発行する。

まずは手元のpython環境でpusherを使えるようにする。

1pip install pusher

そのあと、index.pyをDownloadし、手元のpython環境で実行。

1python index.py

コードの中身を見ればわかるとおり、流れとしては非常にシンプルな３ステップであある。

pusherをインポート
pusher_clientを定義 (app_id, key, secret, cluster, ssl)
pusher_clientからトリガをかけて、メッセージを送信

実際に実行すると、ブラウザで開いていたSTEP1のindex.htmlにポップアップが出てきた。

STEP1〜STEP2で起きている全体の流れ

流れを整理すると、下記の通りになる。

STEP2で実行したpythonコードにより、メッセージ発行イベント(my_event)がPusherのサーバーにあるmy_channelへ飛ぶ
Pusherのサーバーにあるmy_channelにmy_eventが届き、購読者への通知が飛ぶ
STEP1で開いていたブラウザでmy_eventが検出されてポップアップが出る。

使ってみた最初の感想

端的に言って、非常に使いやすいサービスであることが分かった。

PythonとJavascriptでインタラクトする今回のサンプルについても、すぐに試せるし、仕様もわかりやすい。

管理画面で、メッセージの通信量のモニタリングもできる。

よくできているサービスだ。

Pusherの仕組みはシンプルで、Getting Startedもよく出来ており、すぐに使い始めることができる。Sandboxプランで無料ですぐ試せる。

ServerとClientの違いについて

PusherのGetting Startedを通して、基本的な使い方が分かった。

一方で、Pusherにおけるサーバーとクライアントの違いが若干わかりづらい部分があると思ったので、冗長かもしれないが少し整理する。

Pusherでは、全てのクライアントが双方向通信できるのではないか？そうするとサーバーとクライアントの違いは何か？

先のGetting Startedにおいて、STEP1ではイベントを購読するクライアント側、STEP2ではイベントを発行するコード例が紹介されていた。

Getting Startedのコード例を見る限り、クライアント側とサーバー側で、使えるコードが異なっている。APIもClient APIとServer APIで分かれている。

しかし、ドキュメントを見る限り、全てのクライアントは双方向通信ができる。そうなると、クライアントもイベントを発行できるわけで、差がよく分からなくなる。

結論：双方向通信する場合、各ノードはServer APIとClient APIの両方を使うことになる

サーバーとクライアントという言葉に惑わされて勘違いしてしまうのだが、「ServerシステムとClientシステム、２つのシステムにおいて、それぞれServer APIとClient APIを使いましょう」という意味ではない。

単に「メッセージを発行するAPIをServer APIと呼び、メッセージを購読するAPIをClient APIと呼びましょう」というだけなのだ。

２つのシステムで双方向通信をする場合、下図のような全体像になる。

双方向通信を実現する場合のプログラミング上の制約

Server APIとClient APIの働きがわかり、それらを以て双方向通信が実現できることが分かった。ただそうなると、双方向通信を実現する場合の１つ制約が見えてくる。

Server APIとClient APIで、サポートしているプログラミング言語が異なるため、双方向通信をしたいのであれば、両APIがサポートしているプログラミング言語を使わなければならない。

サポートしている各APIでサポートしているライブラリはこちらで確認できる。表で整理すると下記のようになる(2024/05時点)。

サポートしている言語	Client API	Server API
Java	✔️	✔️
JavaScript	✔️	✔️
Swift	✔️	✔️
.NET	✔️	✔️
Unity	✔️
Flutter	✔️
React Native	✔️
Objective-C	✔️
Angular JS	✔️
Python		✔️
Go		✔️
Ruby		✔️
PHP		✔️
Node.js		✔️