「FCM」の記事 - Crieit

PHP+Laravel+FCMでWebプッシュ通知を送る

2018-06-25T11:16:11+09:00

LaravelでFCMを使ったWebプッシュ通知を実装しましたが、検索してもあまりサンプルなどなかったので書き残しておきます。

Firebaseに登録

FCMはFirebase Cloud Messagingなので、とりあえずFirebaseに登録する必要があります。基本的には下記のとおりに行うだけです。

JavaScript Firebase Cloud Messaging クライアントアプリを設定する

このページの最初の方にJavaScriptに設定する方法が書かれたリンクもあります。

Firebase を JavaScript プロジェクトに追加する

このconfigの内容は、Firebaseの画面のProject Overviewというリンクをクリックした先の「ウェブアプリに Firebase を追加」というボタンをクリックすると出てきます。

Service Workerの設定

前述のマニュアルを読んで地味に気づいにくいのがService Workerの設定です。これを行わないと動きません。具体的には下記のページに書かれています。

JavaScript クライアントでメッセージを受信する

なんかプッシュ通知を送信したいのに「受信する」というタイトルなので初めて見た時は関係ないと思って飛ばしてしまって気づきませんでした。

Webプッシュ通知の許可

設定が終わったらあとはどんどん実装を進めていきます。最初は通知の許可です。これは結構みんな経験したことがあると思いますが、ブラウザで急に出てくる「通知を許可しますか？」みたいなやつです。

許可されたらトークンが取れるので、それをLaravel側に送信してユーザー情報に保存します。

import * as firebase from "firebase";
import axios from "axios";

const messaging = firebase.messaging();

messaging
  .requestPermission()
  .then(() => messaging.getToken())
  .then(token => {
    if (token) {
      const params = {
        token,
        user_agent: window.navigator.userAgent
      };
      return axios.post("/fcm-tokens", params);
    }
  })
  .then(response => {
    if (response && response.data.result) {
      console.log('Done');
    }
  })
  .catch(err => {
    console.log(err);
  });

上記のような感じで、ユーザーエージェントなどと紐付けてtokenを保存し、ユーザーのhasManyとして紐付けておきます。というのも、ユーザー毎ではなく操作する端末毎での許可になるので、１ユーザーにつき複数のtokenが紐づく形になるためです。

Laravel側

Laravel側ですが、今回僕は下記のライブラリを使用しました。

brozot/Laravel-FCM: Laravel-FCM

READMEを見てもらえば分かりますが、むちゃくちゃ簡単に必要な処理が可能です。

Webプッシュ通知する端末の登録

上記を使って、Laravel側では下記のようにして保存しました。

    public function store(Request $request)
    {
        $user = Auth::user();
        $fcmToken = FcmToken::firstOrNew([
            'user_id' => $user->id,
            'user_agent' => $request->input('user_agent'),
        ]);

        // 念の為
        if (!$fcmToken->id) {
            $fcmToken->token = $request->input('token');
            $fcmToken->save();
        }

        // 適当にユーザーのグループ名を作る
        $groupName = $user->getFcmGroupName();

        if ($user->notification_key) {
            FCMGroup::addToGroup($groupName, $user->notification_key, [$fcmToken->token]);
        } else {
            $user->notification_key = FCMGroup::createGroup($groupName, [$fcmToken->token]);
            $user->save();
        }

        return response()->json(['result' => true]);
    }

非常に簡単ではありますが、FCMを初めて実装する人は何がなんやら分からないと思いますので説明していきます。

本家のマニュアルにあるように、FCMでは複数の端末に一度にWebプッシュ通知を送る場合には、下記の方法があります。

・トピックメッセージングでは、特定のトピックにオプトインした複数の端末にメッセージを送信できます。
・端末グループメッセージングでは、定義したグループに属する複数の端末にメッセージを送信できます。

つまり例えばある投稿をウォッチしている全ての端末にWebプッシュ通知を送りたい場合はトピックメッセージ、あるユーザーの端末全てに送りたい場合は端末グループメッセージを送る、ということです。

今回のサンプルはユーザーへの通知を想定しているため、端末グループメッセージの説明を行います。

        // 適当にユーザーのグループ名を作る
        $groupName = $user->getFcmGroupName();

グループ名の文字列が必要なため、メソッド化し一意になるような文字列を返しています。

        } else {
            $user->notification_key = FCMGroup::createGroup($groupName, [$fcmToken->token]);
            $user->save();

グループがまだ存在しない場合はまずグループを作成します。作成時には追加するトークンも一緒に指定することができます。取得した通知キーはWebプッシュ通知の際に使用するのでLaravel側でDBに保存しておきます。

        if ($user->notification_key) {
            FCMGroup::addToGroup($groupName, $user->notification_key, [$fcmToken->token]);

グループが既に存在する場合（PCで許可済みでスマホでも許可した場合等）には既に登録したグループに端末を追加するだけです。

Webプッシュ通知する端末の削除

FCMでWebプッシュ通知する端末を削除するのはLaravel側では下記のような処理になります。

        $groupName = $user->getFcmGroupName();
        FCMGroup::removeFromGroup($groupName, $user->notification_key, [$fcmToken->token]);

        $fcmToken->delete();

        if (!$user->fcmTokens()->count()) {
            $user->notification_key = null;
            $user->save();
        }

注意点として、マニュアルにも書かれていますがグループ内の端末が全てなくなった場合は、自動的にグループも削除されます。そのためユーザーに紐づくトークンを全て削除した場合はグループの通知keyも削除しておきましょう。

Webプッシュ通知を送信する

送信は非常に簡単です。Laravel-FCMにかかれている通りそのままです。アイコン指定は追記していますが、httpsから始まるフルURLを指定します。

        $notificationBuilder = new PayloadNotificationBuilder('新着コメント');
        $notificationBuilder->setBody("「{$post->name}」にコメントが投稿されました。")
            ->setIcon(config('app.url') . '/img/icon.png')
            ->setSound('default');

        $notification = $notificationBuilder->build();

        $groupResponse = FCM::sendToGroup($user->notification_key, null, $notification, null);

一点注意点として、Laravel-FCMのREADMEを見ると宛先を配列で指定していますが、今回はうまく動きませんでした。

これはたまたまなのかFCMの仕様なのか忘れてしまった＆今回細かくは確認していないので、もし仕様であれば、一度にWebプッシュ通知を送信する宛先が多い場合は別途バックグラウンドで送信する、等が必要だと思われます。

もしくはトピックグループ送信でも良いと思いますが、管理が非常に大変になりそうだったので今回は使いませんでした。

まとめ

とりあえずざっとにはなりますがLaravelでFCMのWebプッシュ通知を送信する方法をまとめました。とりあえずここに書いた内容を理解できれば、あとは本家のマニュアルの方を見てもスムーズに理解できるのではないかと思います。細かい部分は本家のマニュアルも実際に確認してみてください。

WEBサービスの通知機能実装が面倒すぎるので困った

2018-06-20T08:12:23+09:00

先日Crieitにコメント機能を付けました。そうなると必要になってくるのが、通知機能です。

記事を投稿した人はコメントがついたら通知が欲しいでしょうし、コメントした人も自分のコメントに返信が来たり、同じ記事にコメントがついた場合にはすぐに見たいと思いますので通知が欲しいはずだからです。

通知機能の選択肢

WEBサービスに通知機能を実装する場合、現在だと大まかにふた通りのやり方があると思います。

メール通知

昔からある一般的な方法です。一番無難な方法でもあると思います。通知メールを残しておけば何の通知だったかあとでも確認できますし、メール通知機能さえあれば必要最低限はまかなえると思います。

PUSH通知

FCMを利用したPUSH通知です。メールとは違い、端末に通知が来て直接アプリケーションの画面が開けるため、スピード感がありWEBサービスには向いています。

どちらがいいのか？

最終的には両方の通知機能を実装することでしょう。ただ、個人でWEBサービスを作っている場合や、スタートアップなどがスモールスタートする場合などは何でもかんでも最初から実装しておけばいいというわけではありません。

サービス的に両方絶対必要、ということであれば仕方ないですが、時間に限りがありますし通知機能の実装は非常に面倒ですので、絶対必要でなければどちらかの通知機能に絞った方が良い場合もあると思います。

どちらにどういうメリットがあり、どちらがどれだけ面倒か考えていきます。

メール通知

メール通知のメリットは前述の通り、とりあえず作っておけば最低限大体のことは満たせるということです。ただ、実装方法は色々ありますが、結構面倒な点もあったりします。

サーバー上のメールサーバーを用意する場合

Postfix等を使えば特に外部サービスを利用しなくてもメールを送信することができます。ただ、自分で設定をしなければならないので面倒です。一回くらいなら自分で頑張って設定しようかと言う気にはなるのですが、もしもう１台増やすか、ということになった時などにまた同じ設定をしなければならないのかと思うとうんざりします。

僕は仕事上インフラ周りも触ることはありますが、メールサーバーは正直必要最低限は最初から送信できたりすることもあり、WEBサーバーやDBの設定に比べて扱う頻度が低く、大体次触る頃にはほとんど設定方法を覚えていません。そのためネットで調べながら設定することになり、時々つまづくこともあるのでかなり面倒です。

特に普段サーバー環境構築をしない人からするともっと大変だと思います。例えば下記の記事に設定が書いてありますが、長い設定画面が出てきたあたりで読む気すら起こらなくなると思います。
Ubuntuでメールサーバー構築

メール送信サービスを利用する場合

上記の理由から、SendGridやMailgunメールサービスをつかってメール通知を実装するともっと楽になります。色々と機能もついており非常に便利です。ただ、これはこれでいくつか問題があったりします。

送信数制限

送信数制限があるため、多く送ると費用がかかるようになります。例えばSendGrid等は現在月12000通です。

さすがにそれなら超えないんじゃないか？　と思いますが、１サービスではなく１アカウント毎の制限になりますので、いくつもサービスを作っていて、ある程度メールを送信するしている場合はわりと超えてしまうのではないかと思います。

今は良いけど今後サービス新しく作る場合にどうしようか？　と悩むこともあると思います。

リレー方式の場合はダメな場合がある

僕が愛用しているGCEもそうですが、ポートに制限がかかっている場合があり、リレー方式の送信方法だとブロックされてしまい送信できません。マニュアルはありますがこれもちょっとうんざりする系です。
SendGrid でのメールの送信

API方式がいい

API方式は良いです。一番簡単だと思います。ただ、言語によってはなぜかリレー方式しか使えないライブラリがあったりするので、このあたり気をつけないとローカル環境では動いたのに本番では送信できないとなりますので気をつけましょう。

あとはどの方式にも言えますが、DNSでSPFの設定をちゃんとやっておく必要があります。これをやっておかないとスパムメール扱いされてしまう事が多いです。メールサービスであればマニュアルに書いてあることも多いと思います。

WEB PUSH

FCMを利用したWEB PUSHによる通知です。スマホなどで通知を受け取り、すぐに目的のURLにアクセスできるため、サービスにユーザーを頻繁に呼びこむのに優れています。

単にユーザーに通知を送るだけでなく、トピックを作っておいて、そこにユーザー端末を登録してトピックに通知を送ると登録されているユーザー全員に通知を送ることができる、などもあり、非常に便利です。（もちろん、そのあたりの登録、解除の仕組みなどもちゃんと作らないといけません。自前のDBに保存しておく必要もあります）

通知の履歴が残らない問題

通知の履歴が残らないため、通知を消してしまったり、通知からサービスにアクセスしても一旦どうでもよくて離脱し、再度気になった時にアクセスできない、といった問題が出てきます。（実際にはスマホには履歴が残っているのですが、見るのも面倒で知らない人も多いと思います）

そのためサービス側に独自の通知履歴を作らなければなりません。

独自の通知の実装

独自の通知の実装ですが、これがまた面倒です。というのも、通知というのは色々なところで発生します。例えばフォローしているユーザーやカテゴリに何かが投稿されたり、自分の投稿にコメントがついたり。

つまりDBの構造として単純なbelongsToで作ることができません。通知自体はあまり他のところで使われるものでもないのでpolymorphicであれば割とシンプルに困ることなく作れるかもしれません。何にしろ条件分岐にしろ、関連モデルに共通のメソッドを用意するにしろ、やることは増えるので面倒なのは面倒です。

元はといえば単にユーザーに最低限の通知をしたかっただけのはずなのに…。

フロントとの連携の問題

単に通知一覧を実装するだけであれば問題ないのですが、WEBサービスのヘッダ部分に新着通知アラートをだしたりすることになるとまた面倒なことになります。どこまで閲覧済みかという情報を保存しておかなければならないからです。

フロントエンドと連携する場合、ユーザーの確認とDBの更新のタイミングが必ずしも同じではなくなるため、適当に作ったりするとまだ確認していないのにある一瞬のタイミングで全ての通知を確認済みにしてしまって新着通知が消えてしまったり、逆にフロント側では新着確認済みになったのにリロードするとまた新着が復活してしまう、ということが発生したりします。

Facabookもこの不具合が多く非常に困ったため、Fluxを提唱したという話をどこかで見ました。ほんとに通知機能というのはやっかいなシロモノです。

個人のWEBサービスなら良いのですが、もし仕事でするとなると仕様策定側が便利にしたいと思ってあれこれ勝手に決めてしまうこともあるので大変そうです。

周辺機能の実装

通知を作るとなると、周辺にも色々と機能を実装する必要が出てきます。これも非常に面倒です。元はといえば単にユーザーに最低限の通知をしたかっただけのはずなのに…。

トピックやユーザーなどにウォッチ機能、もしくは通知解除機能を実装する必要がある
ユーザーの個人設定に一般的な通知許可設定を実装する必要がある、もしくはここにも分類毎の許可設定が必要

まとめ

こんな感じで、単に通知機能を作りたいだけのはずなのですが、周辺部分も含めると結構工数がかかってしまい、なかなか厄介です。考えれば考えるほど、こだわればこだわるほど色々できてしまう箇所ですので、いかに絞って仕様を策定するかは非常に重要になると思います。
（メールサービス関連はざっと調べただけですので誤っている情報もあるかもしれません。検討される際は実際に確認してください）

記事を書きつつ気持ちを落ち着けて考えてみましたが、CrieitとしてはとりあえずSendGrid等のAPI送信で試そうかなと思います。一応公式のライブラリの方はAPI方式っぽいので。（SendGrid公式のLaravelやRailsのサンプルはリレーっぽいのでなんか不親切な感じがします）

…と決めたら決めたでまた悩む…。

追記）
FCMにする。

追加）
結局メール（API）も入れました。