Brighter RC2: Mudanças na configuração dos Messaging Broker

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

Em meu artigo anterior sobre o Brighter RC2, abordei as atualizações do release candidate inicial. Hoje, vou focar especificamente nas mudanças significativas no Messaging Gateway do Brighter RC2.

1. Renomeação de Métodos para Maior Clareza

Duas mudanças significativas afetam como você configura subscrições e external buses. Para reduzir a confusão dos usuários, renomeamos:

• AddServiceActivator → AddConsumer
• ExternalBus → AddProducers

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

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

Por que essa mudança? A terminologia anterior causava frequentes mal-entendidos sobre os papéis dos componentes. Embora reconheçamos que a nova abordagem não é perfeita, priorizamos o lançamento da V10. Para a V11, planejamos refinar a experiência de configuração – compartilhe suas sugestões em nossas discussões no GitHub.

2. Configuração Explícita do Mapper de Mensagem Padrão

Definir mappers de mensagem padrão agora requer especificação explícita de tipo. O método auxiliar anterior para cloud event foi substituído pelo registro direto de tipo:

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

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

Se você preferir a implementação anterior, por favor abra uma issue com seu caso de uso.

3. Identificadores Fortemente Tipados

Para combater a “primitive obsession”, o Brighter agora introduz tipos dedicados para conceitos-chave de mensageria:

Tipo Anterior	Novo Tipo	Conversão Automática
string	Id	De string
string	RoutingKey	De string
string	CloudEventsType	De string
string	PartitionKey	De string

A maioria das conversões acontece automaticamente, minimizando o impacto na migração enquanto melhora a segurança de tipos.

4. Configuração Aprimorada de Subscrições

As subscrições agora exigem campos obrigatórios para propriedades críticas:

// Agora OBRIGATÓRIO em todas as subscrições
new Subscription<MyCommand>(
    new SubscriptionName("MySubscription"), 
    new ChannelName("MyChannel"),
    new RoutingKey("my.routing.key")
)

Subscrições de Múltiplos Tipos agora são suportadas. Por exemplo, manipulando múltiplos tipos de mensagem que herdam de uma base comum:

// Manipula tanto OrderCreated quanto ShipmentUpdated (que estendem Event)
new Subscription(
    new SubscriptionName("Operations"), 
    new ChannelName("OperationsChannel"),
    new RoutingKey("my.operations.key")
    getRequestType: message => 
    {
        // Determina o tipo apropriado com base no conteúdo da mensagem
        return message.Header.Topic.Value.Contains("order") 
            ? typeof(OrderEvent) 
            : typeof(ShipmentEvent);
    }
)

Em um artigo futuro vou explicar com mais detalhes.

5. Aprimoramentos nas Publicações

As publicações agora suportam headers padrão e propriedades do CloudEvent:

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" }
    }
}

Conclusão

Essas mudanças no Brighter RC2 melhoram significativamente a segurança de tipos, clareza e flexibilidade do messaging gateway.

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