[Feedback] Brighter can act as event bus and task queue and supports RMQ integration and resiliency

[iancooper]

We have a pre-release .net core version here: https://www.nuget.org/packages/Paramore.Brighter.CommandProcessor/7.0.86-alpha It's only alpha to allow us to shorten namespaces. RMQ handles production workloads, ASB and SQS+SNS support need more work and are still alpha.

Key featues:

• Command Model (the Darker project provides a query model)
• A decorator pipeline allows supporting orthogona events via attributes
• We provide support for wrapping Polly as an attribute based decorator out of the box
• We can handle command in-process or out-of-process via MoM
• We support RMQ today (significant effort to be resilient, especially in container enviroments). ASB and SQS+SNS in progress
• ServiceActivator handles spinning up an event consumer from a console project,; multiple queues per consumer; multiple threads per queue; message pump model.

Key competitors would be Mass Transit (no core version as of writing) and NServiceBus (commercial)

Documentation needs updating for Core (for example we configure in code not in config files now)

https://brightercommand.github.io/Paramore.Brighter/dotnetcore/Brighter.html

https://github.com/BrighterCommand/Paramore.Brighter

[CESARDELATORRE]

We'd love if you guys would like to fork this sample when we have further implementation about Integration Events and Event Bus (this is just initially explained, and not final as need to evolve/improve, too, in the Guide/eBook). We're actually starting that implementation effort, but we'll just create a simple Event Bus based on RabbitMQ just for Proof of Concept and development environment purposes.

For a "Production Ready" event bus we'll recommend either Azure Service Bus, NServiceBus, MassTransit, Brighter, etc. I'll keep track of this issue and we will take it into account for the documentation/Guide/eBook, too, so it is also added as references.

About commands, we're currently using commands but with a simpler approach, not message based. We're using MediatR, from Jimmy Bogard as a convenient way to implement a mediator pattern and apply multiple decorators. For many scenarios this can be good enough. However, if you'd like to implement a fork and use your Command Model based on your Service Bus for a more advanced scenario, we'd love to point to it from the guidance as well.

About microservices integration scenarios, we're thinking about a couple, initially:

• Simple integration based on events between the Catalog microservice and the Basket microservice, so when a product's price changes in the Catalog, an integration event will be raised through the event bus and any subscriber (the Basket microservice in this case) will get it so it can show warnings business messages to the using telling him that the product's price was change compared to the original price when he added the item to the basket.

• Other additional more complex integrations will be done when we advance on a more complex Order state workflow (Accepted, Paid, Shipped, Delivered, Cancelled, etc.), probably based on a Saga, etc., this is all "still coming", not implemented, yet. So bear with us, but any feedback you guys might send will be taken into account. Ian, thanks a lot for your feedback! :)

[iancooper]

Happy to work via a fork.

Just worth noting though:

(1)we already support decorators in or out-of-process i.e. we cover all of Mediatr's scenarios, but we already have Polly integration built into that. In other words we cover what Mediatr does and more

(2) Robust RMQ integration is hard. You'll hit issues with timing between containers for example, that will give you exceptions you will need to manage in a retry loop. I appreciate your desire to implement this, but we already have code that runs large production volumes at a number of web scale businesses right now and available on core right now. We do need to move up to RQM 5+ and pick up its async support though.

If you feel compelled to build this out yourself, go for it. Feel free to look at our code if you get stuck and lift from it if you find that easier.

[iancooper]

PS You can see how we support both interaction styles here: https://github.com/Arc-Lightning/FutureStack

[CESARDELATORRE]

Our point of view: We'd like to create a simple Event Bus implementation, clearly NOT ready for production, and as a learning purpose or proof of concept, only. Something easy to have it running in the solution and decoupled from further infrastructure.

Then, folks could switch to any "production ready" Service Bus in the market, like Brighter, NServiceBus, MassTransit or even Azure Service Bus, depending on the requirements. We'd prefer that approach so we are not giving special priority to any Service Bus in the market, but just making easy to design the app's architecture taking into account an Event Bus in mind that could be easily swapped by a "production ready" Service Bus, like yours. I think it is reasonable so there's no any initial preference on Brighter vs. NServiceBus vs. MassTransit or any other. We will, however, be adopting OSS libraries like MediatR, Polly, Json.NET NewtonSoft, etc. so we don't re-invent the wheel, as long as we are not taking dependency on larger infrastructures. If you guys have single OSS libraries that could be re-used in the example, we would like to evaluate it, for sure.

Future forks/flavors of the app will be taking further and stronger dependencies, like using Azure infrastructure, specific orchestrators, etc. but not for this foundational version. That's why I also think that a fork using Brighter would also be great so folks can see multiple approaches around the same business domain and more importantly, have implementations ready for production. :)

[iancooper]

I appreciate that trying to avoid pulling in a given framework creates an issue of 'backing a horse' which has its own set of problems.

We all want what helps push the community forward. For now we'll fork to show how we handle this. We are intentionally lightweight libraries and not a large framework btw, but I think the key point is the above one.

If you need help getting your cheap bus running, please ping us. We could easily put a shoulder to the wheel

Ian Cooper

On 7 Mar 2017, at 21:09, Cesar De la Torre notifications@github.com wrote:

Our point of view: We'd like to create a simple Event Bus implementation, clearly NOT ready for production, and as a learning purpose or proof of concept, only. Something easy to have it running in the solution and decoupled from further infrastructure.

Then, folks could switch to any "production ready" Service Bus in the market, like Brighter, NServiceBus, MassTransit or even Azure Service Bus, depending on the requirements. We'd prefer that approach so we are not giving special priority to any Service Bus in the market, but just making easy to design the app's architecture taking into account an Event Bus in mind that could be easily swapped by a "production ready" Service Bus, like yours. I think it is reasonable so there's no any initial preference on Brighter vs. NServiceBus vs. MassTransit or any other. We will, however, be adopting OSS libraries like MediatR, Polly or Newton.soft, Json.NET NewtonSoft, etc. so we don't re-invent the wheel, as long as we are not taking dependency on larger infrastructures. If you guys have single OSS libraries that could be re-used in the example, we would like to evaluate it, for sure.

Future forks/flavors of the app will be taking further and stronger dependencies, like using Azure infrastructure, specific orchestrators, etc. but not for this foundational version. That's why I also think that a fork using Brighter would also be great so folks can see multiple approaches around the same business domain and more importantly, have implementations ready for production. :)

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[CESARDELATORRE]

For sure, we'll request your feedback and help. I really appreciate you taking the time to review and suggest approaches. Thanks a lot. I'm sure we'll learn a lot from your experiences and feedback, too. :)

[mvelosop]

Closing this as conversation can be considered finished!

Making an internal note to consider this in the roadmap.