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 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.
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..
Related
I've read the page about the new notifications in Laravel 5.3, and seen some tutorials from Laracasts, but I would like to know what is available in terms of variables etc.
In the Slack API documentation, I can see that I can create buttons in the notification, however, the notification (using SlackMessage) shows that I can't use action() and it throws
Error
Call to undefined method Illuminate\Notifications\Messages\SlackMessage::action()
Does anyone have some information about this?
Thanks in advance!
What I think is you are reading the documentation wrongly. According to Laravel's Slack Notification, it doesn't help you create "button" in Slack.
The Laravel Notification is a mechanism for you to create notification through different channels, like SMS (Nexmo), Database, Emails, Slack. So if you think about this carefully, "button" is actually not a common pattern in these channels, hence action is not implemented here in Slack.
In contract, the action method found in SimpleMessage or MailMessage is actually referring to "call-to-action" button. It helps you create a button in the email nicely. This is not true in other type of notifications, such as DatabaseMessage, NexmoMessage, or SlackMessage. You simply don't (or doesn't make sense) to create buttons in these channels.
If you need to create additional content with SlackMessage, simply extend it and build one for your own.
I have already integrated Stripe payments into one of my websites, and all is working great (and I'm using a unique webhook for this website).
I have just created an entirely different service through another website of mine, and am in the process of integrating Stripe on that website too.
However I have one problem, as far as I can see, I have to use the same webhook for both of my services. This won't work tho!! I really need separate webhooks for each service... is this possible?
PS: I read on Stripe's docs that every event will be sent to every webhook in the list (https://dashboard.stripe.com/account/webhooks).
Please somebody shed some light!
This was such a tidy fix.
Simply log in to your Stripe dashboard, and in the top right click you account name and then click 'Create New Account'.
Props to Matthew for the answer which also matches Stripe's docs
You must use separate Stripe accounts for projects, websites, or businesses that operate independently from one another.
Log in to your Stripe Dashboard and there is a drop down option that shows your current account name on the top left hand side. Select it and add new account.
So I'm looking for a pattern that might help me to solve my problem. it's related to events, and notifications. It goes something like this:
in this case management system, at various points along the workflow, events will be triggered that will require I notify the team members that belong to the instance of that workflow. examples:
boss please reassign this case
bla was approved, begin working on this case
I'm going on vacation, notify my delegate that all my cases are his!
Members in the system can "opt-in" to different forms of notification like email, sms, messenger via their account profile. One user may have multiple notification types they've elected to use.
the structure I'm hoping to use is to have a standard interface for the various notification managers
$smsNotificationManager->notify(Event $event, Array $users)
$emailNotificationManager-notify(Event $event, Array $users)
$messangerNotificationManager-notify(Event $event, Array $users)
Events would be passed to an event handler that would - as one of its tasks - engage the notification handler to notify the member(s)that event occurred. The Notification handler would be responsible for having each specific Notification manager sort out how to notify the people that subscribed to their notifications.
I'm sure there is pattern that I could leverage here. The event will identify people who would need to be notified. The Event Handler shouldn't be concerned with how to notify them.
The notification handler should be able to sort out what types of notifications are available, and figure out how to pass to each manager the event, and all the subscribers.
I'd be adding support for new notification types in the future too. So i'm a bit unclear as to best practices regarding whether or not I should encapsulate the notification types elsewhere, or implement concrete references in the notification handler, Have it sort users, by subscription, set up some case logic in the notification handler and and pass each notification manager the list of users, and the event.
is there an obvious pattern to model this after. Any guidance best practice welcome!
I have created a dashboard using PHP and Wordpress, the problem i'm facing now is that I need to create an alert or a message when ever a new data has arrived in any users dashboard. So, I need to send the users that are currently online in the dashboard, a notification that a new data has arrived for them.
Whenever a data has been added by me for a particular user, an automatic notification should be shown on the that users screen if he is online. I have created the dashboard, but I don't know how to implement this notification.
In short, I want to create something like a push notification inside my website.
Use Atmosphere framework for braodcasting any messages. This essentially uses Websockets in the implementation. But its very easy to do.
I'm coding a team collaboration web app in PHP, and I have a few events that users get notified about through email and/or SMS. The current way I'm doing it is as follows:
Every user has his notification settings in the database as boolean variables.
Say users would be notified when someone comments on the team's page. When the function that posts a comment is called, the same function would contain extra code that checks "who wants to be notified about this?" and then sends notifications to them (which slows down the function a bit).
Is there a more efficient/faster/flexible way to setup notifications? maybe through a script that runs via a cron job? or shall I just keep doing it this way?
I appreciate your help.
I implemented a similar method to the one you're following on a website with a multi-table approach. The users table held the contact information along with opt-in, opt-out options while an event table held the instructions to notify. Several other events were hard coded because of their importance. The thing that set the site apart a bit was a "workflow" area on the user's dashboard that also showed the user what action items they had. We found that most users ignored the emails and dealt directly with that dashboard workflow area. You'd be surprised how many times people change emails or just ignore them altogether.
With 280,000 users and daily visits in the tens of thousands, there was no performance issue noticed. However, the process of queuing emails can be inefficient if you're not careful, so take particular time to benchmark your mail sending functions--its as easy as echoing out microtime before and after the mail send is accomplished--to evaluate its effectiveness. On my current company's site, such improvements yielded a 800% reduction of email queuing time (queuing being the process of generating the emails and submitting them via php mailer to the mail system for distribution)
I'd say have a table that is a queue of notifications. Let the function that post a comment still check "who wants to be notified about this?" but then just log entries containing the messages in this table. Then have a separate process work from the queue i.e. your cron job suggestion.
Depending on your database you may perhaps make use of database events or triggers instead of a cron job. This however have the requirement that your database allow you to put code in your database that will send the SMS or Email. This poses a security risk normally which you may or may not be concerned about in your setup.