• 6
name

A PHP Error was encountered

Severity: Notice

Message: Undefined index: userid

Filename: views/question.php

Line Number: 191

Backtrace:

File: /home/prodcxja/public_html/questions/application/views/question.php
Line: 191
Function: _error_handler

File: /home/prodcxja/public_html/questions/application/controllers/Questions.php
Line: 433
Function: view

File: /home/prodcxja/public_html/questions/index.php
Line: 315
Function: require_once

name Punditsdkoslkdosdkoskdo

Laravel Broadcasting: Notification vs Event

I read laravel documentations about Events and Notifications, it seems we can fire an event and from that event (using ShouldBroadcast interface) broadcast it to laravel echo which i understand, in the other hand we can use Notifications viaBroadcast to do the same, so what's the difference?

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 preform 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.

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 a e-mail use Mail:: without the need for a notification.

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

  • 71
Reply Report
    • I think what the original question refers to is instead of doing event(new ProductPurchased) and the 3 listeners firing, why not use the broadcastOn method in ProductPurchased and not have the notifyClient listener.
      • 2
    • Sure, but the question says that he understands broadcasting. Which is websocket stuff, which is mostly used to show users real-time information inside your application. While notifications are used to send to users. Listeners are just classes that should be triggered after a important action. Its not eventlisteners or notifications or broadcasting , they kan be done all for a certain action. They serve a different purpose.
      • 2
    • @RomanLopez Thanks for the kind words! Broadcasting is still useful when using web sockets. Broadcasting is the solution when using laravel Echo for building a chat app for example.

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..

  • 27
Reply Report
      • 2
    • actually you can make your own notification mechanism with event-listener, but Laravel provide out of the box solution to track your activity, especially if you use database notification because you do not need to know how laravel filter the notification data, laravel provide all things for you. Even slack, nexmo, mail, broadcast you can triggered from event manually, but notification wrap all of this to make more easy to implement.

Warm tip !!!

This article is reproduced from Stack Exchange / Stack Overflow, please click

Trending Tags

Related Questions