Add new `PostDaprPubSub` Reaction

[amansinghoriginal]

Overview of feature request

Proposed Feature: PostDaprPubSub Reaction
This feature request proposes the development of a new Drasi Reaction, named PostDaprPubSub. This reaction will act as a bridge, consuming change events and control signals from one or more Drasi CQs and publishing them as messages to a configured Dapr Pub/Sub component and topic.

Benefits:

• Decouples Drasi from Dapr Consumers: Dapr microservices can subscribe to Dapr topics without needing direct knowledge of Drasi or the underlying data sources.
• Leverages Dapr Pub/Sub: Utilizes Dapr's pluggable Pub/Sub components, resiliency, and observability features.
• Enables Rich Event-Driven Architectures: Allows Dapr services to react to sophisticated, contextual business events detected by Drasi, rather than just raw data changes.

Acceptance Criteria

1. Configuration per Query:
   • The reaction MUST allow configuration on a per-Drasi-query basis.
   • Each query configuration MUST specify the target Dapr pubsubName (the name of the Dapr Pub/Sub component).
   • Each query configuration MUST specify the target Dapr topicName.
2. Event Publishing:
   • The reaction MUST successfully publish Drasi ChangeEvent data (add, update, delete results from a CQ) to the configured Dapr topic.
   • The reaction MUST support an option to publish Drasi ControlEvent data to the Dapr topic.
   • The reaction MUST allow configuration to skipControlSignals if only data changes are desired.
3. Event Formatting:
   • The reaction MUST support publishing events in an "unpacked" format, where individual changes (adds, updates, deletes) or control signals are sent as separate Dapr messages (using Drasi native format).
   • The reaction MUST support an option for a "packed" format, where the entire Drasi ChangeEvent or ControlEvent object is sent as a single Dapr message.
   • The default format SHOULD be "unpacked".
4. Error Handling & Resilience:
   • Configuration errors (e.g., missing required fields) MUST be detected at startup, and the reaction should fail to start or clearly log the invalid configurations.
5. Documentation:
   • A README.md file MUST be included, detailing:
     • The purpose of the reaction.
     • All configuration parameters (e.g., pubsubName, topicName, packed, skipControlSignals) with descriptions, defaults, and whether they are required.
     • Example reaction.yaml configuration.
     • Basic instructions on how a Dapr microservice can subscribe to and consume events published by this reaction.
     • The structure of the published messages for both packed and unpacked formats.

Additional Context

This reaction is crucial for users looking to build reactive systems where Drasi provides the framework for change detection across various data sources, and Dapr provides the backbone for inter-service communication in a microservices environment.

Key Scenarios Enabled:

• Real-time updates to Dapr microservice caches or materialized views based on complex changes in underlying databases.
• Integrating data change events from legacy systems (monitored by Drasi) into modern Dapr-based applications.

Target Users:

• Architects or Developers designing solutions that require sophisticated change data capture and propagation into a microservice ecosystem.

Relevant Dapr Documentation:

• Dapr Pub/Sub Building Block

Would you like to support us?

• Yes, I would like to support you