DEV Community

Cover image for Brighter V10 RC2: Messaging Gateway
Rafael Andrade
Rafael Andrade

Posted on

Brighter V10 RC2: Messaging Gateway

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:

  • AddServiceActivatorAddConsumer
  • ExternalBusAddProducers
// Brighter V9 / V10 RC1
services.AddServiceActivator(....)
        .ExternalBus(...)

// Brighter V10 RC2+
services.AddConsumer(....)
        .AddProducers(...)
Enter fullscreen mode Exit fullscreen mode

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<>)))
Enter fullscreen mode Exit fullscreen mode

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")
)
Enter fullscreen mode Exit fullscreen mode

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);
    }
)
Enter fullscreen mode Exit fullscreen mode

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" }
    }
}
Enter fullscreen mode Exit fullscreen mode

Conclusion

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

Top comments (0)