Conventional Message Routing

You can have Wolverine automatically determine message routing to GCP Pub/Sub based on conventions as shown in the code snippet below. By default, this approach assumes that each outgoing message type should be sent to topic named with the message type name for that message type.

Likewise, Wolverine sets up a listener for a topic named similarly for each message type known to be handled by the application.

var host = await Host.CreateDefaultBuilder()
    .UseWolverine(opts =>
    {
        opts.UsePubsub("your-project-id")
            .UseConventionalRouting(convention =>
            {
                // Optionally override the default queue naming scheme
                convention.TopicNameForSender(t => t.Namespace)

                    // Optionally override the default queue naming scheme
                    .QueueNameForListener(t => t.Namespace)

                    // Fine tune the conventionally discovered listeners
                    .ConfigureListeners((listener, builder) =>
                    {
                        var messageType = builder.MessageType;
                        var runtime = builder.Runtime; // Access to basically everything

                        // customize the new queue
                        listener.CircuitBreaker(queue => { });

                        // other options...
                    })

                    // Fine tune the conventionally discovered sending endpoints
                    .ConfigureSending((subscriber, builder) =>
                    {
                        // Similarly, use the message type and/or wolverine runtime
                        // to customize the message sending
                    });
            });
    }).StartAsync();

^{snippet source | anchor}

TIP

As of 6.41, every node of an application shares one subscription for each conventionally routed listener, so each message is handled once across the cluster. Before 6.41 each node got its own subscription and handled every message. See Subscriptions across multiple nodes to opt back into a subscription per node, and for the upgrade steps.

Handler Type Naming 5.25

By default, conventional routing names topics/subscriptions after the message type. In modular monolith scenarios where you have more than one handler for a given message type and want each handler to receive messages on its own dedicated subscription, you can opt into naming after the handler type instead:

var host = await Host.CreateDefaultBuilder()
    .UseWolverine(opts =>
    {
        opts.UsePubsub("your-project-id")
            // Name listener subscriptions after the handler type instead of the message type
            .UseConventionalRouting(NamingSource.FromHandlerType);
    }).StartAsync();

With NamingSource.FromHandlerType, each handler class gets its own dedicated topic/subscription named after the handler type. This ensures that each handler independently receives a copy of every message. Outgoing topic names are still derived from the message type.

Separated Handler Behavior 6.49

With MultipleHandlerBehavior.Separated, every handler of a message type past the first is its own handler chain with its own listener. A Pub/Sub topic fans out to every subscription on it, so the convention gives each of those handlers a subscription of its own on the message type's topic, named from the handler type the way NamingSource.FromHandlerType names a handler's topic. The sender is unchanged: it publishes to the one topic.

opts.UsePubsub("your-project-id")
    .AutoProvision()
    .UseConventionalRouting();

opts.MultipleHandlerBehavior = MultipleHandlerBehavior.Separated;

Each per-handler subscription is an endpoint of its own with the Uri pubsub://{projectId}/{topic}/{subscription}, so it can be configured, listed and found like any other. Because the topic does the fan-out, a publisher in another process reaches every subscription too.