We work in a traveling company. We sell tickets for domestic flights, international flights, trains, and buses.
Currently, each of these products has its own team members and they use different libraries/tools to develop their product on their own. One team may use RabbitMQ as their message broker between its microservices and another team may use NetMQ and another team may use X and Y.
In one of our products, domestic flight, one of its team members has written a tool named MQTools which is a wrapper over NetMQ messaging library that creates some functionalities over that like Service Discovery/Existence Broadcaster, Data Publisher/Data Subscriber, Work Distributor/Worker and so on.
This tool is used in the domestic flight team for about a year and it answers most of the domestic flight product needs.
There are multiple problems with MQTools:
1- It’s developed just by a single person, and today this person has left the company and we do not have access to him, so now MQTools is a semi blackbox tool for us. Although, I've said semi because it’s not a very big library and we can learn it on our own in about 2,3 weeks but it's a little hard work at least for the first weeks to add new features to that.
2- Another problem that we have with MQTools is that it doesn't have a very good code-base and a lot of code smells could be found in its source code.
3- It uses NetMQ as its underlying message library which it's not a popular and actively developing library on its own and there are no online tutorials/books about it and I think new members don’t like to work on a platform like this.
Now, all of these traveling products like flights, trains, and buses have exactly the same steps but one could have additional steps or the order of the steps could be different based on the product.
Our vision is that we can make an abstraction for these products, so the members of such teams can just write their logic code and so, they will not have any concern about the underlying messaging mechanisms and such stuff. They just have to override the defined steps and write their logic code.
With all of these stories, we can implement such a thing in two ways:
1- Using MQTools which is written specifically for domestic flight product, so it needs to be refactored first to remove its code smells and being fully documented so new members could be able to learn this tool easily. Secondly, it should be abstracted in a way that all traveling products could use that because it's now developed with the domestic flight team in mind only.
2- Using a 3rd-party tool like MassTransit to remove MQTools, because MQTools has tried to implement some functionalities on top of NetMQ which I think it’s like rewriting a tool like MassTransit which works like this on top of RabbitMQ, AmazonMQ, Azure-SB and so on.
MQTools is not exactly a message bus like MassTransit. It has been developed with some extra features than a “message bus” because it didn't have explicit boundaries and now by replacing that, some of those features need to be rewritten using MassTransit.
By using MassTransit instead of something like MQTools we will gain these pros:
1- We’ve removed a black box from our system called MQTools.
2- MassTransit with RabbitMQ has a lot easier learning curve than NetMQ and MQTools so new members have a lot more resources to learn this stack.
3- MassTransit is a stable library that has been there and developed since 2012 and it has been used in many projects.
4- With MassTransit, we don’t have to deal with low-level MQ concepts that exist in NetMQ like message-frames, beacons, pollers and so on.
5- We have some pre-built features like monitoring solutions on top of RabbitMQ such as DataDog or Prometheus/Grafana.
6- We're able to easily switch to other transports like ActiveMQ, AmazonMQ and Azure Service Bus.
And here is MassTransit and RabbitMQ cons:
1- RabbitMQ is a broker and this broker could be a failure point, but NetMQ is broker-less.
2- Some of MQTools functionalities need to be rewritten with MassTransit according to replacement changes.
Now my question is which approach should I choose:
1- Refactoring MQTools, creating documentation for that and abstracting it in a way that can be used in different products.
2- Replacing MQTools with MassTransit and rewriting some of its missing features as an extension on top of MassTransit and abstracting it in a way that can be used in different products.
- It’s also worth mentioning that there’s nothing that could be implemented with NetMQ and cannot be implemented with MassTransit and visa-versa.
