Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
Firebase Cloud Messaging のベストプラクティス を、探している
Search
Sponsored
·
SiteGround - Reliable hosting with speed, security, and support you can count on.
→
gyarasu
February 01, 2020
Technology
1
3.3k
Firebase Cloud Messaging のベストプラクティス を、探している
2020.02.01 PWA Night Conference
https://conf2020.pwanight.jp
gyarasu
February 01, 2020
Tweet
Share
More Decks by gyarasu
See All by gyarasu
QAエンジニア組織立ち上げはじめの一歩
gyarasu
0
78
RESTful Firebase with Vue.js
gyarasu
1
460
Next.jsではじめるPWA
gyarasu
2
1.7k
doda AIジョブサーチ PWAとパフォーマンスの話
gyarasu
0
1.8k
副業時代のプロジェクトマネジメント
gyarasu
3
3.1k
PWA基礎_1
gyarasu
0
310
PWA基礎_2
gyarasu
0
200
PWA基礎_3
gyarasu
0
170
フロントエンドエンジニア (実稼働まで) ひとりでできるもん
gyarasu
0
2.8k
Other Decks in Technology
See All in Technology
Escape from Excel方眼紙 ~マークダウンで繋ぐ、人とAIの架け橋~ /nikkei-tech-talk44
nikkei_engineer_recruiting
0
190
詳解 強化学習 / In-depth Guide to Reinforcement Learning
prinlab
0
370
AI時代のオンプレ-クラウドキャリアチェンジ考
yuu0w0yuu
0
220
Goのerror型がシンプルであることの恩恵について理解する
yamatai1212
1
300
俺の/私の最強アーキテクチャ決定戦開催 ― チームで新しいアーキテクチャに適合していくために / 20260322 Naoki Takahashi
shift_evolve
PRO
1
430
FlutterでPiP再生を実装した話
s9a17
0
130
スピンアウト講座06_認証系(API-OAuth-MCP)入門
overflowinc
0
1k
ReactのdangerouslySetInnerHTMLは“dangerously”だから危険 / Security.any #09 卒業したいセキュリティLT
flatt_security
0
480
SSoT(Single Source of Truth)で「壊して再生」する設計
kawauso
2
320
ADK + Gemini Enterprise で 外部 API 連携エージェント作るなら OAuth の仕組みを理解しておこう
kaz1437
0
170
プログラミング不要! テスト自動化における生成AI使いこなし術
magicpod
1
100
スケールアップ企業でQA組織が機能し続けるための組織設計と仕組み〜ボトムアップとトップダウンを両輪としたアプローチ〜
tarappo
4
360
Featured
See All Featured
My Coaching Mixtape
mlcsv
0
84
DevOps and Value Stream Thinking: Enabling flow, efficiency and business value
helenjbeal
1
150
Embracing the Ebb and Flow
colly
88
5k
Music & Morning Musume
bryan
47
7.1k
コードの90%をAIが書く世界で何が待っているのか / What awaits us in a world where 90% of the code is written by AI
rkaga
61
43k
Thoughts on Productivity
jonyablonski
75
5.1k
Git: the NoSQL Database
bkeepers
PRO
432
67k
For a Future-Friendly Web
brad_frost
183
10k
State of Search Keynote: SEO is Dead Long Live SEO
ryanjones
0
160
The Language of Interfaces
destraynor
162
26k
Sam Torres - BigQuery for SEOs
techseoconnect
PRO
0
220
Into the Great Unknown - MozCon
thekraken
40
2.3k
Transcript
Firebase Cloud Messaging のベストプラクティス を、探している 2020/02/01 PWA Night Conference 吉次
洋毅
誰? • 吉次洋毅(ヨシツグヒロキ) • 経歴 ◦ 某レストラン検索サイトでバックエンドエンジニアなど ◦ 某HR会社でエンジニアをしつつ ◦
フリーランスで受託開発&他社さんの開発やプロジェクトマネジメントのお手伝い • 趣味 ◦ 一人旅 & 写真 & スーパー銭湯 ◦ スマブラ(VIPボーダー周辺をウロウロ・ゼロサムユーザ) ◦ ポケモン(約20年ぶりにはじめました) @gyarasu
使ってる??
FCMによるWeb Pushが届くまで ① FCMからトークンを取得 ④ プッシュ送信を受信 ②トークンをサーバに送信 ③ FCMに処理を投げる
FCMによるWeb Pushが届くまで ① FCMからトークンを取得 ④ プッシュ送信を受信 ②トークンをサーバに送信 ③ FCMに処理を投げる 送信方法がいくつかある
複数のデバイスに送信する方法は2つ https://firebase.google.com/docs/cloud-messaging/js/send-multiple
よくみたら色々あった Node.js Admin SDKリファレンス: https://firebase.google.com/docs/reference/admin/node/admin.messaging
FCMでのPush送信方法いろいろ • CURL / send(Admin SDK) ◦ 単一のトークンを指定して送信 • マルチキャスト(Admin
SDK) ◦ 複数のトークンを指定し送信 • トピックメッセージング ◦ 特定のトピックにオプトインした複数のデバイスにメッセージを送信 • デバイスグループメッセージング ◦ 定義したグループに属する複数のデバイスにメッセージを送信
FCMによる送信方法Decision Tree(暫定)
FCMによる送信方法Decision Tree(暫定) やってみたけど、 ちょっと苦労した
トピックメッセージングのハマりポイント • トピック購読管理の難しさ • ユーザ単位での送信状態の管理の難しさ デバイスグループメッセージングのグ ループ管理も同様の課題あり
トピックメッセージングのハマりポイント • トピック購読管理の難しさ • ユーザ単位での送信状態の管理の難しさ デバイスグループメッセージングのグ ループ管理も同様の課題あり
トピック管理の難しさ
トピックの購読状態の管理 ① FCMからトークンを取得 ④ プッシュ送信を受信 ②トークンをサーバに送信 ③ FCMに処理を投げる
トピックの購読・購読解除の流れ topic, tokenの 組み合わせを保存 ・購読(subscribe) ・購読解除(unsubscribe) ・送信リクエスト メッセージ配信(publish) FCM FaaSなど
データベース
FCMとDBの状態の整合性 topic, tokenの 組み合わせを保存 ・購読リクエスト ・購読解除リクエスト ・送信リクエスト ・購読(subscribe) ・購読解除(unsubscribe) ・メッセージ配信(publish)
FCM FaaSなど データベース 何らかの原因で データが消失 FCMから購読状態を取得す ることはできない
DB上のデータとFCM上での実際の 購読状態の整合性が合わなくなる
DB上のデータとFCM上での実際の 購読状態の整合性が合わなくなる ・DB上では購読してないのに Pushが届く ・DBの上では購読状態なの にPushが届かない
DBのデータ更新とFCMの購読・非購読は Atomicな処理にする
ユーザ単位での 送信状態の管理
通知設定の単位と細分化されたトピック 営業 事務 技術 設定 : 購読トピック = 1 :
n
細分化トピックが引き起こす通知の嵐 営業 事務 技術 トピックメッセージングは、あく までも「トピック」に対して通知 を送る
設定とトピックが1 : 1になっていない場合 ユーザにとって過多な通知になり得る
細かいセグメントで 送信先を制御したい場合は マルチキャストでの送信が良さそう
Decision Tree途中経過 ここはわかった!
トピックメッセージングの選択基準 • 受信設定の単位とトピックが1:1になっている場合 • トピックの単位が単純である場合 ◦ 基本的にはコンテンツの単位が良い ◦ 年齢や性別のようなユーザ属性や、行動ログ等の要素を掛け算してトピック分 割すると、条件が変動するたびに頻繁にトピックの購読・解除を行う必要があ
るのであまり向かない
まとめ • まずはサービスとしてのPush通知の要件・仕様をしっかり検 討してからどの方法で送るか考える(最重要) • トピックメッセージングが向いているパターン ◦ 設定と購読トピックが1:1である場合 ◦ 細分化されたトピックで送信しても問題ない場合
• 細かい条件で送信対象を抽出したり、条件が頻繁に更新され る場合はマルチキャストが良さそう ◦ トピックやデバイスグループ管理をしないで済む ◦ 1回の送信で500トークンという制限あり
※スキップしたスライドも含めてSpeaker Deckで公開します @gyarasu ありがとうございました!