Laravel Broadcasting: Notification vs Event

After thinking a lot, i found out that they are made for different things, here's what i understood:

Notifications:

Consider facebook, everytime you login you see bunch of notifications about things that happened while you where away, also if you are present you see live notifications..

meanwhile you're getting emails about notifications that you want.. this is exactly what Laravel Notifications is doing. you can use notify method on your eloquent models such as App\User about something like OrderApproved which will do whatever you planned it to do for you like sending sms to that user. and also you can save one instant of that notification on database so when user comes back he or she can see that you have approved their order..

Events:

it's when something happens, like when a new user is created and you want to do different things like sending verification email, sending verification sms and.. this is why you create an event so that you could handle different logics of that event using listeners. when it comes to broadcasting, you can use ShouldBroadcast interface on your event and from there you can sync data with your admin panel that a new user is registered. this will be useful when admin is watching list of users and without reloading the page you could user Laravel Echo to receive that event on admin panel and append new registered user to the list.

Conclusion:

it really depends on what you need, if you just want to update something in your interface, maybe events are what you need. but if you need to do more you can use notifications.

in the end events are used when you need to do things when something happens while notifications are report of what just happened.

hope it help others..

What the provided answer lacks imo is that they are in most cases used both instead of 1 or the other, which seems to be the tone of the provided answer/question.

An event is something significant in your application. Let's assume your application is a Webshop.

A significant action in your webshop can be Product Purchased . When a product is purchased you need to do a lot of different steps. Putting this all inside a controller and potentially in several different places can get very messy and not clear.

So a good approach would be to use a Event called ProductPurchased . This event can have Listeners, those listeners are in this case all the steps you need to perform when a user purchases a product.

e.g.: ProductPurchased (event)

• BillClient (eventlistener)
• GenerateInvoice (eventlistener)
• notifyClient (eventlistener)
• ...

Let's say we want to notify our client with a text-message and an email when they purchased a product.

So on the notifyClient event-listener we can create a Notification . This notification is responsible for sending a message to the client. This can be a SMS/Slack-message/Email/...

And like you mentioned both Events and Notifications can be put on the Queue or can be broadcasted. Broadcasting is mainly used in combination with Laravel Echo and the use of Websockets.

You choose notifications when you want to send something to different channels. Mail/SMS/Slack.. If you only need broadcasting you can just use ShouldBroadcast. Just like when you only want to send an e-mail use Mail:: without the need for a notification.

Notifications are a nice way to group the same 'message' to different destinations.