Which Message / Command / Event Bus to use

[webdevilopers]

The example by @yvoyer features a custom implementation of the Event Bus e.g..
But it will also show how to integrate with Symfony components.

Another custom example by @juliendufresne:
https://github.com/php-ddd/php-ddd-bundle/tree/master/src

Of course there is also the @SimpleBus MessageBus by @matthiasnoback::
https://github.com/SimpleBus/MessageBus
I currently use it in my Symfony projects:
https://github.com/SimpleBus/SymfonyBridge

And not to forget @thephpleague Tactician by @rosstuck:
https://github.com/thephpleague/tactician

Another one is @PHPMessageBus by @nilportugues:
https://github.com/PHPMessageBus/messagebus

Opinions?

[webdevilopers]

Another solution I recently discovered is @prooph recommended by @sandrokeil:

• http://getprooph.org/
• https://github.com/prooph

What are your experiences @sandrokeil? You use it for @zendframework only, not @symfony, right?

[sandrokeil]

@webdevilopers The prooph components are framework agnostic. You can use it in/with every framework/library/application. You can use the interop container factories or create the instances manually.

The prooph demo app uses Zend Expressive. We have a prooph Symfony bundle where you can see how to integrate it with Symfony. There exists a prooph Laravel package too. A prooph PSR-7 Middleware is also availabe.

The prooph components are very flexible and have a Command Bus, Event Bus and Query Bus which can be used independently or together. Maybe it looks complicated at the first sight because of the configuration driven approach, but I hope there are enough examples to get a quick start. Take a look at the prooph Gitter Channel. There are many awesome people which can answer your questions. I guess there are some Symfony people there.

[sandrokeil]

Seems you have missed the Broadway library. I can not compare Broadway with the prooph components. It would be great if you can share your results of the comparison. I can say that prooph has many adapters for different systems/libraries, has a strong community and active development. It is open, extendable (plugins) and very flexible.

What are your requirements for the decision?

[webdevilopers]

Thanks @sandrokeil for your feedback!

I havn't really "decided" anything yet. Since I read a lot of tutorials by @matthiasnoback I tried @SimpleBus. I'm currently working on two big legacy projects and most of the stuff is already refactored in Symfony2. That's why I tried the bundle with the Symfony Bridge.

Soon I will start to refactor the code adding the events.

I will continue to concentrate on a Symfony Integration and a library that offers a full Message Bus for Commands, Handlers, Queries and Events.

Unfortunately I won't have the time to try out all the other libraries. That's why I'm very thankful for feedback or other recommendations.

[sandrokeil]

Alright. I guess Broadway and the prooph components are the top players here. The prooph components should have all the features that you need and have adapters for Doctrine, MongoDB, ZeroMQ, Bernard and FlyWheel and has Snapshot (for Event Sourcing) support with different adapters like memcached.

[rosstuck]

Just a heads up since some folks miss it, Tactician has a Symfony bundle as well: https://github.com/thephpleague/tactician-bundle

That said, it doesn't do event bus or anything else, since I think that's a different subsystem. It's pretty easy to build yourself either way, Tactician is mainly there to save you a couple hours when you're tired of doing it yourself or just want to make it a little easier to try.

I mainly use it combined with Broadway, which works pretty well. Hope that helps! :)

[mablae]

Hello guys,

very interesting discussion. Also I need to make some decision on this topic for my own projects.

At the moment I am using the SimpleBus Symfony2 bundles mainly because it was Mathias blog that got me started to think in a more "decoupled way". What is nice about these bundles is the painless integration with RabbitMq as an asyncronous bus. Everything is "bundled" and configured. Just start as many worker threads you like and offload work from request cycle.

But for me it feels, like SimpleBus is more a Proof of concept project in terms of usage count and
releases. It works as it should, has extension points and so on. Meaning I could not tell you anything
I miss right now, but the project feels kinda "abadoned".

Right now I am thinking about Tactican or Prooph as an alternative as there "seems" to be more active community around them.

Since Prooph is utilizing the React PHP Event Loop there is no support for my beloved RabbitMq yet, but there is ZeroMq.

DIsclaimer: I am using the SimpleBus without the EventBus neither do I have full CQRS/ES. Just a central bus to access from different UserInterfaces like CLI, REST-api, Webapp... Even this simple layer to protect business logic is a wonderful simplification.

[webdevilopers]

Thanks for your feedback and mentions on Twitter @mablae !

Looks like we share the same experiences. @prooph actually looks huge - maybe to big for my current projects. But it has some awesome adapters for snapshots. ATM I'm not using this feature yet.

I'm starting to use (A)ES soon. And @rabbitmq looks very promising too.

[matthiasnoback]

@mablae It may be good to note that SimpleBus has not been abandoned. It's just that there won't be a lot of development, since it's very small and simple anyway and new features don't need to be added to existing packages.

Anyway, SimpleBus is so very simple, it doesn't really help you with an actual CQRS/ES project. I'd look for a framework in that case.

[codeliner]

Hi, cool to see some maintainers of different packages here.

@webdevilopers :

@prooph actually looks huge

Why?

If you're only looking for a CQRS oriented message bus library you can use prooph/service-bus and that's it. If you want to process messages async pick one of the available adapters (rabbitMQ is coming soon)

If you want to go the full CQRS+ES route you can add prooph/event-store and maybe also prooph/event-sourcing to your stack and you have everything you need to get started (including replay and snapshot support)

Anyway, @sandrokeil has already listed the advantages. I just want to stress the point that our community is very active. No day without a new question, discussion or talk about CQRS and/or ES (sometimes also other topics) in the prooph chat. Extremely fast response times (for an open source project) when someone has a question or encounters problems. And everybody is welcome to join. No matter if you're using prooph, SimpleBus, Tactician, Broadway or whatever lib because a lot of questions are not related to a specific lib but more to understand the whole topic.

What lib you want to use depends on a lot of different factors. prooph for example provides loosely coupled components but also the entire stack because all components share some common classes (mainly the message related classes) so that they can work together without bridging forth and back.
Also prooph offers a fully event-driven plugin system with fine grained extension points so you can inject your custom logic everywhere. This comes at a cost: it is more complex than for example the decorator approach used in SimpleBus and the middleware approach used in Tactician.
But again it is no problem to use those libs together with prooph/event-store. I know that some of our users do this in their projects and that's totally fine.

@mablae prooph does not use the React PHP Event Loop (atm), we only use reactphp/promise for the query bus. @prolic and others use prooph together with rabbitMQ and/or ZeroMQ in microservices architectures and as I mentioned earlier a rabbitMQ package is on its way. See https://gitter.im/prooph/improoph?at=574effb5f44fde236e527241

Best,
Alex

[webdevilopers]

Thanks for the update @codeliner ! Really looking forward for a RabbitMQ implementation then!

[codeliner]

@webdevilopers check https://github.com/prolic/HumusAmqp
our adapter will use this lib. Maintainer is @prolic who is also a maintainer of prooph components so you get both with the same high qualitiy ;)

[prolic]

Rabbit mq support can be expected in first beta the next month.
Am 03.06.2016 17:58 schrieb "webDEVILopers" notifications@github.com:

Thanks for the update @codeliner https://github.com/codeliner ! Really
looking forward for a RabbitMQ implementation then!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#12 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AAYEvOe4zufenM7JIZkGimOosdhvLBbwks5qH_rBgaJpZM4IZsPO
.

[mablae]

@prolic Will https://github.com/prolic/HumusAmqp be React compatible? Awesome!

[prolic]

Currently react compatibility is not on my roadmap, but I'll think about it.

[mablae]

@prolic Ah, thanks for the quick reply. I had the misunderstanding Prooph would use/need the EventLoop.
@codeliner already corrected me on that. I thought no Promise without Loop? Nevermind. Your repo is bookmarked 😄

[nilportugues]

I've used myself: @SimpleBus, @thephpleague's Tactician and obviously my @PHPMessageBus

I have used them in enterprise environments and are in production. So that's good for all 3 and all of them are maintained. As of personal experience, all work well with CQRS.

So it's all a matter of taste.

PHPMessageBus

For instance, I'd use the one that goes best for your approach. Out of the box, clear and strict Command, Event and Query then @PHPMessageBus. It also has common middleware ready (logs, cache) using PSR standards.

Downside, PHP7 only and no Laravel and Symfony bridges (yet). Still integration is dead easy. Good side, async-eventing (workers and consumers) out of the box.

SimpleBus & Tactician

If you're looking for popularity then @SimpleBus, @thephpleague's Tactician, but neither actually separate Command and Queries (downside).

Their commands allow to return responses. Can be easily fixed by extending Command and removing the return statement. Query class is absent, but can be created by extending their Command. Problem solved here.

@thephpleague's Tactician has lots of packages out there adding functionality. I don't know about @SimpleBus, but I know it's really easy to extend it.

Conclusion

I won't say use mine, just because I'm clearly biased. Just try to build something with any of them. It will work.

[nilportugues]

On @prooph ... I know @Ocramius is actually using it these days. He tweeted about it a couple of days ago.

Maybe he can share with us his experiences so far.

[Ocramius]

If you need event sourcing, then simple buses are not sufficient, IMO. Without EventSourcing, you can pick whatever you want.

Prooph and Broadway provide transactional wrapping of operations performed around an event stream, while in the other components you'd have to design or enable such transactional wrapping yourself.

While transactional wrapping may seem trivial, it may become a mess if:

• your commands are executed in an asynchronous way
• your commands are dispatched in sequence, rather than in nested transactions

At that point, you are not really far from just designing the command bus yourself anyway (heck, a command bus is really simple to implement!). You'd find yourself implementing optimistic locking here and there, and it is no fun at all.

Therefore, pick something that is proven to be working well within the context of CQRS+ES (prooph/broadway). I personally went for Prooph because its design allows for more customization and decoupling of domain from framework (yeah, you'll get to coupling anyway, unless you want to become crazy).

/cc @malukenho - maybe you got more opinions on this?

[malukenho]

I fully agree with @Ocramius, I like the way that prooph solve problems and leave us free from itself. It does not get in my way, so I like it a loot.

Additionally I still need to write something similar to it: https://twitter.com/LeonWeemen/status/623997244912627712

[nilportugues]

Got to admit prooph looks really good. Nice (and a lot of) work there!

Thanks for showing up @Ocramius 👍

[sandrokeil]

@webdevilopers We are working on a @prooph Symfony CQRS + ES demo app and bundles for event store and service bus (CQRS). So you can it use in your Symfony projects soon.

[prolic]

Amqp extension for Prooph ServiceBus is now available. Docs are still missing, but it's already usable.

[webdevilopers]

That's great news guys! Would love to see @prooph become some kind of de facto standard for my PHP CQRS apps based on Symfony w

Hope the docs will be added soon. Until then:

• https://github.com/prooph/proophessor-do
• https://github.com/prooph/proophessor-do-symfony

[sandrokeil]

@mrook has prooph and broadway compared in his slides.

[webdevilopers]

Feel free to join the discussion and share your experiences @DevSander. Found your question on the DDDinPHP Google Group:

• https://groups.google.com/forum/m/#!topic/dddinphp/fmTw3kDZK6s

[webdevilopers]

Feel free to share your recent experiences @patkar.

[enumag]

@prolic Which message bus implementation would you recommend now that prooph/service-bus is deprecated?

[prolic]

I didn't check all of them in details, but symfony/messenger looks promising. If you don't need plugin support (or middlewares), you can also write your own in an hour.

[webdevilopers]

@enumag The current @prooph event-store-symfony-bundle provides a middleware for the symfony/messenger component (from version 4.3) which handles starting/committing/rolling back a transaction when sending a command to the bus:

• https://github.com/prooph/event-store-symfony-bundle/blob/master/doc/messenger.md

Works like a charm. If you are using the current prooph version and you only have read model projections you don't need the service-bus any more.

Currently it only seems to be required for implementing process managers. The symfony messenger does have an event-bus but the events have to be dispatched manually.
If you want to totally skip using the service bus then you need to implement a middleware for the symfony messenger event bus that automatically dispatches the events when a prooph aggregate changed.

But maybe @weaverryan already created a symfony cast for that? :)

[enumag]

@webdevilopers Can you tell me how to use this with prooph/event-store v8? I'm using the asynchronous prooph/event-store-client which is a problem because I can only return a promise and not a real value from a middleware.

[webdevilopers]

I only used the messenger for commands and queries so far.

I'm recently trying to figure out how to make process managers listen to the events fired by the aggregate root via messenger command bus.

In order to replace this:

prooph_service_bus:
    event_buses:
        default_event_bus:
            plugins:
                - 'prooph_service_bus.on_event_invoke_strategy'
            router:
                type: 'prooph_service_bus.event_bus_router'
                routes:
                    'Acme\Context\Domain\Model\Foo\Event\FooCreated':
                        - 'Acme\Context\Infrastructure\ProcessManager\FooPublisher'

That way the service-bus can be completely removed.

And maybe these lines already implement this:

services:
    my_eventstore_transaction_middleware:
        class: Prooph\Bundle\EventStore\Messenger\EventStoreTransactionMiddleware
        arguments:
            - '@my_transactional_event_store'

• https://github.com/prooph/event-store-symfony-bundle/blob/master/doc/messenger.md

Maybe the contributor @Lctrs or @codeliner can tell us more.

[Lctrs]

I don't think that's what you're looking for (if I understood what you're trying to achieve).

The Prooph\Bundle\EventStore\Messenger\EventStoreTransactionMiddleware class is just a middleware for symfony/messenger. Middleware concept in symfony/messenger is very similar to PSR-15. You can read more about them in symfony's documentation.

[enumag]

Never mind, prooph/event-store-symfony-bundle is for prooph/event-store v7. It isn't meant for v8. And for the reason I mentioned I doubt it ever will be.