I have a question
I have a simple system where a User creates a Booking
After a user has created a booking, an email and a SMS will be sent to the user.
I have though of multiple ways to approach this
After the booking was made, send the email and the SMS(blocking)
After the booking was made, Fire an event that is queueable and has two listeners. One sends the email. The second one sends the SMS.
After the booking was made, Fire and event, that will queue 2 jobs, one that sends the email, the second one sends the sms.
Option 1 is a no-go since it is blocking and doesn't have a retry to my Transactional Email provider or SMS provider.
Option 2 is do-able
Option 3 is do-able
In the future I want to be able to send the same email/sms without the BookingConfirmation event, so I will eventually need jobs that can be queue'd without the event.
Or is the event part just overhead and can I queue the jobs directly from the Controller instead of firing the event?
I am basically asking if I should use the Events at all or just use Jobs?
Thanks!
Events are useful because you can fire one event and have multiple action independently.
That means if in the future you want to have a third action, if you use events you can just add another event callback, meanwhile if you skip the events and directly put the jobs into the queue, you have to modify the controller to put the third action.
Convenience lies in the fact you don't have to alter any method in order to add new functionality.
In the end of the day, it's up to the developer. Events provide better code between each action. But performance wise, I think it is the same.
I would put all the tasks as Jobs in a queue, you then fire events (last line of job) when the Job is done, so you can do any follow up actions or things you want to do to inform the use.
So then you can have a job for each task and keep them simple, and also less exceptions or errors to track on each one.
The system I am using at the moment for example uses the event to trigger the next job, but other tasks I fire multiple jobs at once.
Eg.
user clicks booked.
dispatch job email
job email is queued
Job email is processed
Job email sends event
Event picked up by listener
Listener dispatch Job SMS
job SMS is queued
Job SMS is processed
Job SMS sends event
Event picked up by listener
anything else you want to do...
might sound a lot of steps but all are short and then simple to follow and update.
Related
I am using Laravel 7.x
I have a multistep method that logs analytics based on step/actions and that is tied to an offer. In the 2nd step we run a GetMoreUserData::dispatch() job to grab more details about the user from a 3rd party API.
This can take 1-3 minutes to get the results, hence why we moved to the job.
After the user finishes the form, there was is logic to add additional data in the table from the 3rd party API, which now is unavailable since it's in the job.
How would a system design be if you'd want to match the results to that analytic after the fact?
I could pass in $analytic->id to the GetMoreUserData job, but that class has nothing to do with "analytics" and we also wanted to make a cron to run this Job against older users who don't have the additional data.
Would an event work?
OfferSubmitted event that passes in the analytic id? and the job can reference it?
I'm in a bit of a pickle
I want to create a webhook listener to Stripe's customer.subscription.trial_will_end event to send a customer an email letting them know billing will start and giving them cancellation info, but I can't work out how to test it works without waiting a day between each test, i.e. setting the trial period for 4 days, and the event being fired when there's 3 days left.
The Stripe docs give a method for testing trials, but this doesn't fit my use case as the only thing that doesn't work using that method is the trial_will_end event. The CLI can send webhook events, but again the trial_will_end event is not implemented.
How can I test this functionality without having to wait a full day between tests?
There are not currently great ways to manage time-dependent events like this. You will need to seed some test data to generate such events. For a given day of testing through, you can re-use a recent trial_will_end event (say evt_123) using the CLI resend function (doc):
stripe events resend evt_123 --webhook-endpoint we_321
This will let you re-test your endpoint to handle the event & send the email multiple times, ingesting the same 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 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..
I am working on a blueprint to send and Receive email messages.I looking for best practice.
We have to send , for example 1000 messages on click of a button. How to Use SNS and SQS to send messages right away? Is it a good idea to create one SNS request to create 1000 message in a queue?
Is there any way to schedule 1000 messages ?
We receive messages, whats the best way to use SNS and SQS to process the messages?
It would probably be best to put 1 message on a queue on the button click so the user doesn't have to wait. Then have a different process that take messages off the queue and sends the emails or queues up another 1000 messages, one for each email.
Don't think of it as sending 1000 emails with the click of a button, thinking of it as scheduling an email job.
Don't know all that you are trying to do, but you probably also don't want to do a 1000 message load while the user is waiting for a response after a button click.
I would consider, have 2 SQS queues (at least), the first queue is used to schedule the batch job, on a mouse click you insert a single job, i.e. 'send this email to 1000 people' as Travis R suggested.
Another job could poll Q1, see the 'send these 1000 people this email, and it could then create 1000 SQS messages into Q2, one per email address.
A third process (perhaps multiple of them), would watch Q2 and send a single email from the list, and delete the message. Using this method you could throttle you send rate down quite a bit to adapt to your ISP's restrictions, either with the SQS settings, or by limiting how often you 'email a single email' job is schedule to run.
Also consider using amazons SES and setting up another process to monitor bounces and complaints - which you are bound to have if you are kicking off 1000+ emails at a time.
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.