アプリケーション REST API の一部としてWeb フックを実装しようとしています。
最初は、API コンシューマーがエンティティ更新イベントに登録するためのメカニズムの実装を検討しています。そのため、エンティティが変更された場合、そのエンティティの変更イベントに登録されているすべての Webhook を呼び出します (また、登録プロセスの一部として、API コンシューマーは追加のフィルター基準を含めて、関心のあるエンティティのサブセットのコールバックのみを受け取るようにすることができます)。の）。
現在、これはユーザーが開始した変更にはうまく機能し、ゆっくりと変化しますが、変更の洪水が発生した場合にこれをどのように処理するのが最善かについて心配しています-たとえば、UIで実行される一括アクションの一部として、またはAPI コンシューマから発生する変更の洪水。
これまでのところ、次のことを検討しました。
- ある種の非同期プールを使用して、エンティティごとにコールバックを実行するだけです。ここで見られる問題は、スケールであり、Web フックにサブスクライブするアプリケーションに害を及ぼす可能性があります。
- Webhook 登録ごとに、たとえば 10 秒のウィンドウで変更のレコードをキューに入れ、影響を受けるエンティティのリストを含む 1 つの Webhook 通知をサブスクライブにプッシュします。 、イベントがちょろちょろと入ってくるだけの場合 - これは、特に Web ファームのシナリオでこれを実装する場合に、いくらかのオーバーヘッドと複雑さをもたらします。
- 一括アクションを Web フックとして実際に公開します。したがって、一括削除が実行された場合、コンシューマーはこれをサブスクライブします。そのため、個々のエンティティ変更のフックを設定しても、一括更新/削除などのエンティティ変更イベントは受信されません。一括アクション Web フックを介してこれを処理する必要があります。
追加の詳細として、このアプリケーションの一括アクションには、10 から約 100,000 のエンティティが含まれる可能性があります。
これをどのように実装することにしたかを明らかにすることができる一括アクション用の Web フックを実装した人はいますか?