うな(｡･ε･｡)

Android, iOS, AppEngine まわりのめもめも

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 とか考えなくて、何でも良いから変更をぶん投げたい。

上記の理由を踏まえ、次のようなあーきてくちゃを考えてみた。

  1. DB サービスは、Entity の変更をすべて PubSub サービスに通知する。
  2. 通知フィルタサービスは、PubSub からの通知を購読し、通知すべき情報をフィルタリングし、実際に通知を行なう。
  3. 通知サービスは通知を行なう。

まあ、大仰にサービスを分けなくとも、コードだけでも分けることが出来れば十分。3. は Amazon SNS, SES にぶん投げる事が多いと思います。

A/B テストしたい！とか、管理画面で文言テンプレート変えたい！などとなってくると、流石にサービスとして分割した方が良いでしょう。

というもうそうを垂れ流すだけで記事を終わる ( ´ー`)。о

もっと読む