「そして物語は更に何度目かのアプリ内通知再実装を迎える」というタイトルで話してきました．スライドは以下です．
前回開催のKyoto.なんか #2では「そして物語は何度目かのアプリ内通知再実装を迎える」というタイトルで話したのですが，今回はその後日談 (?) の話をしました．
とにかくストレージ周りで苦労をしたくない，そしてできるだけ生に近い状態でデータを取り扱いたい，というモチベーションから，バックエンドのストレージにS3を採用し，RSS (Atom) ファイルをPUT (or PATCH) することで，低い労力でスケーラビリティを確保するというアーキテクチャを提案しました．
実際のS3をバックエンドとしたアプリ通知実装は，個人の趣味アプリでPoC的に実装した程度なので，実際に高い負荷が与えられた時にどうなるのかというのは身をもって体感していませんが，まあある程度はいけるんじゃないでしょうか……という見解でいます (とはいえこれは実際にやってみないとなんとも言えないでしょう)．
スライドの後半に出てくる，「onetime tokenを用いたS3からのfetch」については，発表中に「Pre-Signed URLsを用いれば似たようなことができる」という指摘を頂戴しました．ありがとうございます．セキュリティの要件にも依りそうですが，これを使うと対応できそうですね．
またスライドの方のブコメにも付いていましたが，「Amazon STSを使う」という方法でも対処できるようです．知りませんでした．
発表後の懇親会で議論した内容としては，
- ユーザ数が多いとPUTやGETする為の金銭的コストがばかにならないのではないか
- 複数の通知を1つに束ねる場合にRSSだと難しいのではないか
というものがあり，確かに……となりました．
前者の「金銭的コスト」については，確かに配膳する対象のユーザが増えれば増えるほどかさんでしまうので，実サービスに投入した時にうっかり破産，という風にならないような工夫が必要だなあと思いました．ここらへんは既存ストレージの管理コストや開発コスト等とのトレードオフになりそうな印象を抱きました．
そして後者の「複数の通知を1つに束ねる」というのはなかなかの難題だと感じました．例えば「Aさんがいいねをしました」という通知と「Bさんがいいねをしました」という通知をそれぞれ独立した1通ずつの通知にするのであれば，素朴に各々を1つのエントリにして，片一方を追記すれば良いので実装は単純ですが，仮に「Aさんがいいねをしました」という通知が来た後に「Bさんがいいねをしました」という通知が発火した際は「AさんとBさんがいいねをしました」という新たな通知文言となって届く，というような要件を満足したい時はそこそこ複雑な実装が求められることとなるでしょう．
こういう場合は追記するだけでは機能を実装できないので，過去の通知を舐めて，同種の通知をまとめて1つの新しい通知エントリにした後に不要なエントリを除去するというような実装になりそうですが，そうすると保持する通知件数に齟齬が生じる (例えば，フィードは10件の通知項目を保持しておいてほしいのにもかかわらず，その10件が同種の通知であった場合は1件にまとめられてしまい，通知画面が寂しくなる) 可能性があり，もう少しひねった実装にする必要がありそうです．なんらか工夫をする必要がありそうですね．大変だ．
という感じでまだまだアプリ内通知の設計・実装についての悩みは尽きないわけですが，ひとまず現状のステータスを更新したという次第です．今後も頑張ります．
なお，自分個人としての思いは「OSに通知機能があるなら，自前実装せずにそれに乗っかったほうが良い」というものです．しかしそうも言ってはおれん時もある．人生のようです．よろしくお願いします．
