超技術的ネタなので、qiitaかzenn.dev かと考えたんですけど、なぜか note.com に投稿するしょっさんです。朗報です。今回の Summer'22 に関連して、近々 Salesforce Pub/Sub API が GA します。

gRPC に従ったお陰で、http/2 や多言語でのサポートを期待できる点が強みです。

Platform Event(変更データキャプチャ) などのイベントストリーミングなやりとりを CometD ではなく gRPC で全て置き換えが可能です。今後のイベント駆動アプリケーション開発がスムーズになり、イベント駆動の進んでる某諸国では、相当なゲームチェンジャーになる可能性があります。

これにより、Salesforce でのデータCRUD やイベントをトリガーに、他システムとの連携が Pub/Sub で実現できます。もちろん、他システムのイベントをトリガーにして、Salesforce へ連携することも同じ手順で可能なわけです。

日本だと、サービスの根底に同期(Multi-phase commit)文化があるので、結果整合性よりACIDが好まれています。ポイントに絞って考えるよりも、提供するサービス全体の特性によって、結果整合性でも良いケースは多いものです。ですから、ACID を一部取り込んだサービス全体のアーキテクチャプリンシパルは、BASE であって良いのです。すべてのサービスが厳密にACIDでなければならないという考え方は、少し横に置いていて良かろうかと。

そして、イベント駆動型を Pub/Subで実現できることにより、イベントバスを中心に据えた某SOA的ESB時代が返り咲く可能性もあります。ただそれは、SOAでいうESBを使ったアーキテクチャ構造に似ているだけの話です。Pub/Sub の利点はバックエンドのサービスを、権限委譲した上での正しいマイクロサービス化も実現できるわけです。

マイクロサービスで語られる ESB っぽい API ゲートウェイ・マネジメントとのちがいは、フロントエンド側でAPIをカタログから探して構築すると言うよりも、各マイクロサービスがイベントストリーミングプラットフォーム上に流れてくる、どのイベントを購読するのか、がポイントです。新しいサービスができあがったら、どんなイベントを放り込むのか、どんなイベントを取り出すのか、各サービス側が決められるのが強みです。

「あるものを探す」から、「提供できるものをだす、欲しいものを得る」をサービス側が判断できるようになります。より、疎結合の世界。

また、イベントストリーミングを介して全てのイベントのやりとりがなされるのであれば、どのようなイベントが発生したか、全ての記録も可能です。イベント駆動スゴイ。

来たれ、イベント駆動の世界。