Closed18
Laravel Notification
スーまとめ
- resource_type, resource_id →通知に紐づけるモデルなどを格納する
- notifiable_type, notifiable_id →通知先。例としてはUserなどを指す
- 基本的に何かを通知に紐づけることを考えるのであれば、拡張した方が良い
参考
スーさすがmpywさんだ・・・
スー概要
拡張した方が良さそう
- 保存したいNotificationについては拡張したDatabaseのクラスをviaメソッドに追加
- 1.について保存したい項目に合わせてtoArrayメソッドも記述しておく(場合による)
- OrderUUIDはいるだろうな。。。
スーUUIDについて
スー特定のユーザーにのみ運営からの通知を送りたい場合を考慮しようとするとどうなるんだ・・・？
スー何かイベントがあったときに通知を送る系は、プロセスが多くなりすぎなければ、
オブザーバーで監視させて、値が入ったときに通知をDatabaseとメールで送るにした方が良さそう。
ただ、WEBサーバーのリソースを結構使うので、その辺りの設計をちゃんとやらんといかん。
スーリスナー
スーリスナー、サブスクライバー、オブザーバーの使い分け
- モデルに紐づけた方が良いもの→オブザーバー
- イベント単体に紐づけた方が良いもの→リスナー
- イベントをグループとして捉えて管理して、紐づけた方が良いもの→サブスクライバー
と理解した。
このスクラップは2022/05/04にクローズされました