Brighter V10 RC2: Messaging Gateway

This content originally appeared on DEV Community and was authored by Rafael Andrade

In my previous article on Brighter RC2, I covered the initial release candidate updates. Today, I’ll focus specifically on the significant changes to the Messaging Gateway in Brighter RC2.

1. Method Renaming for Clarity

Two major breaking changes affect how you configure subscriptions and external buses. To reduce user confusion, we’ve renamed:

• AddServiceActivator → AddConsumer
• ExternalBus → AddProducers

// Brighter V9 / V10 RC1
services.AddServiceActivator(....)
        .ExternalBus(...)

// Brighter V10 RC2+
services.AddConsumer(....)
        .AddProducers(...)

Why this change? The previous terminology caused frequent misunderstandings about component roles. While we acknowledge the new approach isn’t perfect, we prioritized shipping V10. For V11, we plan to refine the setup experience – share your suggestions in our GitHub discussions.

2. Explicit Default Message Mapper Configuration

Setting default message mappers now requires explicit type specification. The previous cloud event helper method has been replaced with direct type registration:

// V10 RC1
services.AddBrighter(....)
        .MapperRegistry(registry => registry.SetCloudEventJsonAsDefaultMessageMapper())

// V10 RC2
services.AddBrighter(....)
        .MapperRegistry(registry => registry.SetDefaultMessageMapper(typeof(CloudEventJsonMessageMapper<>)))

If you prefer the previous implementation, please open an issue with your use case.

3. Strongly-Typed Identifiers

To combat primitive obsession, Brighter now introduces dedicated types for key messaging concepts:

Previous Type	New Type	Automatic Conversion
string	Id	From string
string	RoutingKey	From string
string	CloudEventsType	From string
string	PartitionKey	From string

Most conversions happen automatically, minimizing migration impact while improving type safety.

4. Enhanced Subscription Configuration

Subscriptions now enforce mandatory fields for critical properties:

// Now REQUIRED in all subscriptions
new Subscription<MyCommand>(
    new SubscriptionName("MySubscription"), 
    new ChannelName("MyChannel"),
    new RoutingKey("my.routing.key")
)

Multi-Type Subscriptions are now supported. For example, handling multiple message types that inherit from a common base:

// Handle both OrderCreated and ShipmentUpdated (which extend Event)
new Subscription(
    new SubscriptionName("Operations"), 
    new ChannelName("OperationsChannel"),
    new RoutingKey("my.operations.key")
    getRequestType: message => 
    {
        // Determine appropriate type based on message content
        return message.Header.Topic.Value.Contains("order") 
            ? typeof(OrderEvent) 
            : typeof(ShipmentEvent);
    }
)

In future article I’m going to explain it with more details

5. Publication Enhancements

Publications now support default headers and CloudEvent properties:

new Publication<SomeEvent>
{
    Topic = "some-topics",
    MakeChannels = OnMissingChannel.Create,
    Source = new Uri("test-app", UriKind.RelativeOrAbsolute)
    DefaultHeaders =  new Dictionary<string, object> 
    { 
        { "x-custom-header", "value" } 
    },
    CloudEventsAdditionalProperties =  new Dictionary<string, object>
    {
        { "extra", "/my-app" }
    }
}

Conclusion

These changes in Brighter RC2 significantly improve the messaging gateway’s type safety, clarity, and flexibility.

This content originally appeared on DEV Community and was authored by Rafael Andrade