Summary
Add native support for Azure Event Hubs as a CAP transport option.
Motivation / Problem
CAP currently supports several transport providers, including Azure Service Bus, Kafka, RabbitMQ, Pulsar, and others, but it does not provide native support for Azure Event Hubs.
For teams running workloads primarily on Azure, Event Hubs is a common event streaming platform and is often easier to adopt than introducing an additional broker solely for CAP integration. At the moment, users who want to use CAP together with Event Hubs need to rely on indirect workarounds, such as bridging through Kafka-compatible endpoints or introducing another transport product into the architecture.
This creates extra operational complexity, adds configuration overhead, and makes Azure-native adoption less straightforward for event-driven systems built on CAP.
Proposed Solution
Introduce a new transport provider for Azure Event Hubs, with a configuration experience similar to existing CAP transport integrations.
At a high level, the feature could provide:
- a dedicated package, for example
DotNetCore.CAP.AzureEventHubs
- a
UseAzureEventHubs(...) extension method for CAP configuration
- support for publishing CAP messages to Event Hubs
- support for consuming messages from Event Hubs and dispatching them through CAP subscribers
- integration with CAP message headers, retry flow, and transport abstractions as much as possible
- clear documentation about supported scenarios, constraints, and any differences from other transport providers
I would be happy to contribute the implementation if the maintainers think this direction fits the project and if the expected scope can be aligned first.
Alternatives Considered
The main alternative is to use one of the already supported transports instead of Event Hubs, such as Azure Service Bus or Kafka.
Another workaround is to use Event Hubs through its Kafka-compatible interface. However, this is still an indirect integration path and may not provide the clearest CAP user experience, especially in terms of configuration, operational expectations, and Azure-native documentation.
For Azure-focused teams that have already standardized on Event Hubs, native support would be simpler and easier to adopt than introducing a different transport product only for CAP.
Expected Impact
This feature would improve CAP's usability in Azure-centric environments and make the transport ecosystem more complete for users who rely on Azure messaging and event streaming services.
The expected benefits include:
- better alignment with Azure-native architectures
- lower adoption cost for teams already using Event Hubs
- fewer custom workarounds or bridge solutions
- broader transport coverage for CAP without changing its core programming model
Feature Scope
Transport (e.g., RabbitMQ, Kafka, Pulsar)
Additional Context
A previous issue asked about Event Hubs support: #469. At that time, the response was that there was no plan to support it.
I am opening this request to revisit the idea and first confirm whether the maintainers would be open to accepting such a contribution now.
If the direction is acceptable, I would like to follow the maintainers' preferred scope for a first version, including documentation, tests, and any project-specific contribution expectations.
Summary
Add native support for Azure Event Hubs as a CAP transport option.
Motivation / Problem
CAP currently supports several transport providers, including Azure Service Bus, Kafka, RabbitMQ, Pulsar, and others, but it does not provide native support for Azure Event Hubs.
For teams running workloads primarily on Azure, Event Hubs is a common event streaming platform and is often easier to adopt than introducing an additional broker solely for CAP integration. At the moment, users who want to use CAP together with Event Hubs need to rely on indirect workarounds, such as bridging through Kafka-compatible endpoints or introducing another transport product into the architecture.
This creates extra operational complexity, adds configuration overhead, and makes Azure-native adoption less straightforward for event-driven systems built on CAP.
Proposed Solution
Introduce a new transport provider for Azure Event Hubs, with a configuration experience similar to existing CAP transport integrations.
At a high level, the feature could provide:
DotNetCore.CAP.AzureEventHubsUseAzureEventHubs(...)extension method for CAP configurationI would be happy to contribute the implementation if the maintainers think this direction fits the project and if the expected scope can be aligned first.
Alternatives Considered
The main alternative is to use one of the already supported transports instead of Event Hubs, such as Azure Service Bus or Kafka.
Another workaround is to use Event Hubs through its Kafka-compatible interface. However, this is still an indirect integration path and may not provide the clearest CAP user experience, especially in terms of configuration, operational expectations, and Azure-native documentation.
For Azure-focused teams that have already standardized on Event Hubs, native support would be simpler and easier to adopt than introducing a different transport product only for CAP.
Expected Impact
This feature would improve CAP's usability in Azure-centric environments and make the transport ecosystem more complete for users who rely on Azure messaging and event streaming services.
The expected benefits include:
Feature Scope
Transport (e.g., RabbitMQ, Kafka, Pulsar)
Additional Context
A previous issue asked about Event Hubs support: #469. At that time, the response was that there was no plan to support it.
I am opening this request to revisit the idea and first confirm whether the maintainers would be open to accepting such a contribution now.
If the direction is acceptable, I would like to follow the maintainers' preferred scope for a first version, including documentation, tests, and any project-specific contribution expectations.