Despacho del evento y sin manejadores

this is more of a philosophical problem than a real one: it's unlikely you'll decide to dispatch events that have no handlers

Thank you for this solution of "philosophical" problem :) That was exactly my case: I'm dispatching message by Symfony, but for handling I'm using external Go-handler

I have one more interesting point about the event dispatch after we call flush on doctrine. What if a messaging system such as RabbitMQ is temporary down. Your code just has completed the transaction, but you might lose consistency because the event was not delivered to the messaging system. How is it possible to tolerate such as failer?
We could log the error. And the developer will try to figure things out and restore consistency later on.

I think the best approach to prevent such a failure is to save the event into the local table and send it to the messaging system via CRON. It will ensure that the message will be sent or rollback if the transaction has failed due to some reason. What do you think about it?

Hey Max A.!

Yes, this is a big, complex topic. I don't know if it will fully answer your question, but here are some details about this type of "atomic" problem in general: https://symfony.com/doc/cur...

Let me know if it helps :). I'll admit that this is not an area I am an absolute expert in. In general, when RabbitMQ is down, I believe the idea is to have a "fallback" storage mechanism for those messages - like a local database. There is currently no built-in fallback mechanism like that in Messenger. However, you could (I believe) wrap your "dispatch" in a try-catch and then either (A) rollback the other changes in a catch or (B) dispatch a different message (maybe that even has the original message inside of it) that would route to a local transport.

Cheers!

"Try-catch" won't solve the problem of the message has been sent to the rabbit, but the transaction has not been completed, for example, the constrain problem (email must be unique).

Hey Max A. !

Sorry for the slow reply - I had a family matter come up.

> "Try-catch" won't solve the problem of the message has been sent to the rabbit, but the transaction has not been completed, for example, the constrain problem (email must be unique).

You're totally right. I believe the thinking on this (but I'm far from an expert) would then be that you would commit the transaction first, then dispatch to Rabbit. THAT dispatch() would be surrounded by a try-catch so that, if delivery failed for some reason, you could send the message to some sort of "local" fallback system.

Let me know if this helps :).

Cheers!

Hi! I have the same question, because the dispatch() method doesn't throw a exception or any kind of throwable, so there is no way to know if the message has been dispatched at all. Someone has a workaround for this situation?

Hey John!

I believe that if dispatch() fails to deliver the message, then an exception *would* be thrown. For example, if you dig a bit into the amqp transport, you'll find this - https://github.com/symfony/... - you can see that if sending fails, that TransportException is thrown.

Does that help? Are am I talking about the wrong thing here? :)

Cheers!

Hmm, in what circumstances would we use events? Registering a user is a good example of multiple things that need to occur, but using an event system seems to add a layer of complexity without apparent benefits.

What is it for, to create a system to allow 3rd party Devs to "hook in" to and modify the process or something? 🤔

Hey Cameron,

Events allow you to add *some* extra changes without needing to overwrite the whole method for example. But if some third-party code does not have events - the only way to do some changes is overwriting that means you would literally overwrite some code even that one you don't need to change. Usually it comes to just copy/pasting some third-party code to your classes and use them instead. So, events add some complexity, but at the same time it makes third-party code more flexible - you literally can put some *your* code into third-party one. Because editing third-party code directly, i.e. editing files in vendor/ directory isn't option, right? :)

So, it depends, but in some use cases events helps a lot. But definitely not all third-party code needs them, so you shouldn't just blindly add events to your code that someone uses as third-party code, there should be some good reasons for this.

I hope it's clearer for you now!

Cheers!

Thanks, so the use case appears to be if I write a piece of code that I intend on allowing other developers to "hook" into. So if I'm building an app without this requirement, it would be less complex and therefore correct to build the app without events and instead use a controller that calls a service to complete the work?

"without needing to overwrite the whole method" - I don't see this being a problem, if the code is written correctly, i.e. where the controller calls a method that has abstracted away the complexity of the operation into a service. Adding "another" piece of code to execute should be as simple as making a single call to a service that will do the work (from the controller) - which removes the complexity of using events which only seem to further complicate development.

Apart from the above use case (allowing devs to hook into a process I've developed) it's not clear at this point in the training that there's another use case for events.

Hey Cameron! It's nice to hear from you :)

I agree with Victor that events are a good way for third-party libraries to allow users to hook into the system and extend its behavior. Another reason I can think of for using events in your own application (assuming that you are able to modify any part you want) is when you want to apply the Open-Close principle, if you want to close a specific service from being modified, then, you can dispatch an event so any other part of your system can listen to it and then perform any required action. And, perhaps if you're thinking into evolving your app into a micro-services architecture, it may help orchestrating the business rules.

Cheers!

Hey Diego, thanks, so it sounds like its a kind of notification service for other servers in a microservice architecture. That's interesting 🤔

Yea, at least those are the reasons that I can think of where you can benefit from using events. A good example of it is Doctrine, it allows you to hook into basically any step of the lifecycle of an entity

It also appears that it would be a good way to build a decoupled app - the app could then be split into seperate microservices without as much refactoring.