[RFC] Add Messenger component example

[yceruto]

Now that 4.1 stable is happily released I'd like to put in the board this nice component and think about how we can introduce it here.

My Proposal

"Blog posts subscription" or whatever you want to call it. The goal is to show an input box where any user can submit their email to subscribe for new articles, when a new article is created, we would dispatch an async message through the bus to send all emails to the subscribed users.

About The Implementation

To keep it simple, we might need a fake transport to simulate the async process and go without the amqp extension. Other details later if this example is approved.

---

If you have a different idea where this new component can be used or how it should be used, please put it here. Thanks.

[ogizanagi]

Fake transport could delay handling to kernel.terminate by storing messages in-memory and process messages once the request is served. That's actually perhaps a cheap "transport" we could provide in the core. I already rely sometimes on such a system with the EventDispatcher to delay some events (of course it has limitations).

Or if we want to go the worker way (which probably makes more sense to fully sample async), a filesystem or doctrine transport with https://github.com/php-enqueue/messenger-adapter.

cc @sroze

[yceruto]

Or if we want to go the worker way (which probably makes more sense to fully sample async)

Yes, a filesystem transport would be nice for this example.

Is it planned to introduce such transport in the core?

[ogizanagi]

@yceruto : Don't know, but I don't think so. I don't see much benefits from re-implementing what is already available through php-enqueue and already usable thanks to the messenger-bridge.
The AMQP transport was only motivated by providing a sensible built-in adapter out-of-the-box AFAIK.
Perhaps we'll add other transports, but that'll probably be very limited.

[sroze]

IMHO I think that we could have a Doctrine one, but that’s basically it :)

…

On Fri, 8 Jun 2018 at 12:15, Maxime Steinhausser ***@***.***> wrote: @yceruto <https://github.com/yceruto> : Don't know, but I don't think so. I don't see much benefits from re-implementing what is already available through php-enqueue and already usable thanks to the messenger-bridge. The AMQP transport was only motivated by providing a sensible built-in adapter out-of-the-box AFAIK. Perhaps we'll add other transports, but that'll probably be very limited. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#808 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAxHEcMsl_BMhSDIquzSyB9qaloZxK-pks5t6ly4gaJpZM4UTrKz> .

[thePanz]

@yceruto I implemented a filesystem transport here: https://github.com/thePanz/messenger-filesystem-transport
It started before the Messenger component was "official" and I just wanted to play with it.
In the end I enjoyed the implementation and ended up adding some "compression" features and using it in a pre-production environment :)

[yceruto]

With 4.3 we have a Doctrine transport, ideal for this example.

@javiereguiluz what do you think about this one?
Do you think that an example of this feature could make the demo too complex?

[javiereguiluz]

Yes, I'm afraid it would complicate it too much.

I'd like to have "a mechanism" to create variants of the Symfony Demo app. It'd be great to have a complete and complex example of Worflow + Demo app, of Messenger + Demo app, etc. But I don't know how to do that while keeping those "variants" in sync with the evolution of the main Demo app.

[jkufner]

@javiereguiluz Such a mechanism for demo apps would be really nice. I'm working on a framework which integrates with Symfony and this is exactly what I'm missing. It would be really nice to have links from the documentation pointing to full working examples — the demo apps.