PubSub なもうそう
Entity の変更を通知したいことが多々ある。たとえば、「メッセージを受信しました」は、recipient_id
が自分の Message
オブジェクトの追加を検知して、通知を行なっていると言える。
このハンドラーは例えば Rails であれば Model の after_create
などで管理されることになる。
しかし、このような書き方をすると "Entity の管理" と "通知" の責務が一緒くたになってしまう。
分割!分割!と叫ぶわけではないけど、モバイルの Push 通知の台頭で、通知の負う役割範囲が大きくなってきた。 以前までは Email で通知すれば十分だったものが、Email, APNS, GCM と通知サービスの幅が広くなってきている。Web においても、更新された情報を元にページをリアルタイムに更新したい、という欲求が芽生えるときがある。このような場合、WebSocket だとか Polling だとか考えだすと、「通知」と一言で呼ぶものはいかに幅広いものか。 他には、ログやアナリティクスの要望も大きい。通知が失敗したら、再送をしたいという要請だってある。そして A/B テスト…と。 場合によってはユーザの locale によって i18n したりね…
ここまでやることが増えると、分割したほうが良いというのは自然な欲求だと思う。
Entity だって after_create
とか考えなくて、何でも良いから変更をぶん投げたい。
上記の理由を踏まえ、次のようなあーきてくちゃを考えてみた。
- DB サービスは、Entity の変更をすべて PubSub サービスに通知する。
- 通知フィルタサービスは、PubSub からの通知を購読し、通知すべき情報をフィルタリングし、実際に通知を行なう。
- 通知サービスは通知を行なう。
まあ、大仰にサービスを分けなくとも、コードだけでも分けることが出来れば十分。3. は Amazon SNS, SES にぶん投げる事が多いと思います。
A/B テストしたい!とか、管理画面で文言テンプレート変えたい!などとなってくると、流石にサービスとして分割した方が良いでしょう。
というもうそうを垂れ流すだけで記事を終わる ( ´ー`)。о
もっと読む
- Amazon SNS で Push 通知を一斉配信するときのフィルタリングについて考える | Developers.IO : http://dev.classmethod.jp/smartphone/sns-push-filtering/