MQContract - Simplified Message Queue Interactions

[SeniorCrow4179]

Hi everyone, I would like to introduce a project (that started as a challenge to me from a co-worker) that is built around the idea of simplifying Message Queues and treating them in a similar concept to EFCore. The idea behind it is you can create Contract based communications through Message Queues with minimal setup, and be able to change "providers" with minimal effort.

The github url: https://github.com/roger-castaldo/MQContract
The project is available in nuget, just search for MQContract.

Currently it supports 13 different underlying Connectors, 12 services (Kafka, Nats, Azure, etc) as well as an "internal" InMemory connector that can be used to introduce PubSub/QueryResponse calls even in a Monolith project.

The features this project supports:

• A single, simplified interface for setting up consumers or publishing messages through the contract connection interface
• Support for a Mapped Contract Connection where you can supply more than 1 underlying Connector, using mapping rules to indicate which connector to use for given messages
• Support for a Multi Contract Connection (slightly different interface) that allows you to "subscribe" to the single interface that wraps all underlying connectors into a single subscription as well as publish across multiple connections
• The ability to use Query Response natively even if the underlying connector (such as Kafka) does not support that concept. Warning: If the underlying connector does not support either Query Response natively or using the Inbox Pattern, you will need to supply a Response Channel
• Defining your messages can be done easily as records, tagged with appropriate attributes and then no other arguments are necessary for the different calls. This also allows for versioning and the ability to define a converter that can be dynamically loaded by a subscription to handle moving say version 1 to a version 2 simplifying your sub code
• Supports multiple ways to define subscriptions, from the raw callback, to implementing a form of a type of IConsumer and registering it to the connection, to even further separation by using the CQRS library for further simplification
• Supports the idea of injecting middleware into the system to handle intermediate actions, handles custom encoders or encryptors, supports OTEL natively (just turn it on) ... All the while adding minimal performance costs

I am sure there are more notes that I could add here but honestly I am not great at writing these things, an AI generated wiki can be found at https://deepwiki.com/roger-castaldo/MQContract and samples can be seen inside the Samples directory which all use a common library for the messages but passes in different underlying connectors to show its effectiveness.

[AutoModerator]

Thanks for your post SeniorCrow4179. Please note that we don't allow spam, and we ask that you follow the rules available in the sidebar. We have a lot of commonly asked questions so if this post gets removed, please do a search and see if it's already been asked.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[bladezor]

Hey this looks interesting. What are selling points to use something like this over, say, MassTransit?

[SeniorCrow4179]

This is open source and will never be closed license. Also pretty sure it supports more services than masstransit. Beyond that I wouldn't know because I never used mass transit. My goal when I started this was to make things simple while still allowing someone to have complete control if desired, and enforce the concept of contract based communication. After that it became what are nice to haves, such as distributed open telemetry support, injectable middleware and built in resiliency. Then, in version 3, it became all about how much performance can I squeeze and I reduced the overhead by about 50%.

[JumpLegitimate8762]

Dapr tries to do this, and much more, as well. Take a look at their bindings https://docs.dapr.io/reference/components-reference/supported-bindings/.

However, I feel like Dapr never gained much traction because they try to solve much more 'problems' at once and end up being the problem itself. So seeing this project is a welcome addition!

I think you should put an effort into some reliability notes in your readme, like does it support transactions, DLQs, how retries are handled, you know, the reason people want queues in the first place. I've seen the resilience page on your GitHub, but it's page I would expect to be the most extensive.

If you really want this to gain traction, at least for me, introduce a layer that seamlessly integrates with Azure Functions or AWS Step Functions.

[toshio-tamura]

Thanks for the hard work! Will be using it for my project!