Best practices when migrating from NServiceBus

[Meteor]

Hi,

I've implemented some microservices with NServiceBus already and I want to reimplement the project in MassTransit (mostly because it's free and maybe performs better).

I've read the documentation and searched around but I've got no precise answer to my questions. I've several microservices (like Identity, Passenger, Flight, Hotel, Fiscal, etc.) which are implemented as a console application in a docker container so that I can easily scale them.

I kindly ask please mention the question number while you are answering ;-)

1. NServiceBus usually makes one queue per microservice, is it a good practice in MassTransit too? or you suggest one queue per group of related messages?
   
2. In some microservices I've many message types (commands, events). Do I need to register each consumer one by one?? like:

cfg.ReceiveEndpoint(host, "customer_queue", e =>
{
   e.Consumer<MessateType1Consumer>();
   e.Consumer<MessateType2Consumer>();
   e.Consumer<MessateType3Consumer>();
   e.Consumer<MessateType4Consumer>();
   ...
});

       or is there a way to register all at once? I've seen many examples but all of them have only one consumer to register :-(

3. Is it better to have one C# class for each consumer, or to have one class for consuming many message types (maybe a workaround for registering many message consumer at once)?

 

4. I've a base Command interface type, so that I can make sure all commands have specific properties (and so for events), but I use the child interface for Send/Publish. Is it okay? because in the docs it's written:

 

A common mistake when engineers are new to messaging is to create a base class for messages, and try to dispatch that base class in the consumer – including the behavior of the subclass. Ouch. This always leads to pain and suffering, so just say no to base classes. 

So I've no idea is it related to what I'm doing or not? because I don't dispatch the base class, I only dispatch child classes (but maybe somewhere I consume a base class).

I really appreciate your kind attention, and thank you for making such a great framework :-)

 

 

[Eric Piraux]

Hi,

I worked with  both frameworks and I find them quite equivalent.

About your questions, here are my cents:

1. When you talk about microservice you maen Saga, aren't you? A saga/micropservice can subscribe to different messages and is therefore subject to register to multiple queues. It is always better (whatever the frameworks is) to have only one type of message per queue.
2. For the same reason (one message type per queue) you should register only one consumer type to one queue. But indeed each consumer must be registered. There are different ways to register in MT
3. Still for the same reason, it is a best practice to have on class per consumer, as the class extends IConsumer<T> where T is the message type you want to consume.
4. Having a base command interface can help, for instance to declare common properties, but you should avoid to put business specific properties in base interfaces. Another option is to have a base interface and interfaces that extend the base one to be able to subscribe to more generic or specific messages.

I hope that will help you ...

Eric

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.
To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/b42b150d-b2e6-4b5b-af75-0024959cb6a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Meteor]

Hi Eric,

Thank you very much for your useful response.

Let me add some points about your answers.

1. Yes, some microservices have saga and some don't. Anyway the important thing is that maybe the number of message types among all microservices reach to hundreds or thousands of types, so is it efficient to have this count of queues? Doesn't it cause any performance issue with RabbitMQ? What's the best pattern considering performance while you have thousands of message types?

2. So there is no way to register all consumers at once and I should register all consumers one by one?

Thank you again dear Eric.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

[Eric Piraux]

I don't think that having thousand of exchanges/bindings/queues is a problem for RabbitMQ, but someone else has an opinion on this ?

But the concern is talking about priorities of messages. If you put all message types in a single queue you'll be soon or later be confronted to messages that have higher priorities than other. 

This is not really an issues according to your initial question : the same question exists in both frameworks.

For your point 2 you should look at the different ways to register consumers. You can use factories, or you could develop your own reflection mechanism (like it exists in NServiceBus)

Eric

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/b42b150d-b2e6-4b5b-af75-0024959cb6a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-dis...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/254fab9f-1e18-4327-899a-80ccae8d0e58%40googlegroups.com.

[Meteor]

Thank you Eric for your prompt response.

All things are now clear, however other opinions about thousand of exchanges/queues are very welcome.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.

To post to this group, send email to masstrans...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/masstransit-discuss/b42b150d-b2e6-4b5b-af75-0024959cb6a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "masstransit-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to masstransit-discuss+unsub...@googlegroups.com.