I'm allowing a user to upload a post which includes an image and some related information as well as select the promotion fee[bronze,silver or gold].In my /post controller i'm validating the request and then sending a request to another API[third party api for performing payments].The API takes the user phone number and the promotion fee selected and does the payment transaction.So i made the Transaction model[used to save details concerning the completed transaction]to dispatch a created event since i want to save the other post related information only if the payment is successful.
I've tried to create the listener for the TransactionCreatedEvent but i can't find a way to pass the post related data into the listener in order to save them. I also tried to use the closure by calling the listen method on the Event Facade inside the post controller to no avail.
Mh, i'm not quite sure if i undestood you question correctly, but in you case, you could either relate the Transaction with the post, or pass the Transaction and the Post Model to any event or to a job, and then do whatever you want with the data in the event handler or job
Related
I am using Laravel Livewire, I currently have a form that captures a user's address information, then it needs to submit that to a 3rd party API (it's for billing information).
The issue that I am facing is that the UI doesnt update / livewire doesnt call render until after the entire method has run - which looks on the frontend like the UI is frozen / system isnt doing anything as the API is slow and takes a few seconds (15 - 20) to give a response.
I want to be able to trigger a browser event to display an alert saying the request is processing / show an alert banner on the page that it is processing before making the API request, process the API request, then display the results.
Currently I have identified the following ways to make this happen:
make the updates on the frontend, fire off an event with the data needed. Laravel event listener handles the API call, and emits a result event that the livewire component listens for, then the livewire component updates the page with the results.
make the updates on the frontend, dispatch a job to run in a queue worker, emit an event that the livewire component listens for, update the page with the results.
emit an event from the livewire component to itself, the livewire component then listens for that event and processes the API request, then updates the frontend with the results.
emit an event from the livewire component to itself to update the UI with processing info, while it still runs the API process in the original method call, and then updates the UI once the API gets a response
My thoughts are, what would be best practice here? All the above solutions require a different amount of work to get running, and solution 1 and 2 looks like complete overkill for such a simple process.
Does this come down to preference? Or is there actually a best practice way to do this in livewire?
And additionally, is there another way / simpler way to do this that I havnt mentioned above?
Your feedback is appreciated.
I would probably create a job and then return a response to the user. Then instigate Livewire polling that can check for the job being complete. If the API takes 15-20 seconds then polling once per second should be fine.
You might want to store the state in the database so that the job and the livewire component can communicate with each other. If you don't need to keep the data, using the cache to communicate between job and component would be a good alternative.
I am creating an application with Laravel and VueJs. In this application a user can create an event. These events have participants. In my application the user fills out all of the event information and participants information and then clicks submit.
What I am looking for guidance on is how to best structure this in the backend. What I need to accomplish is the following:
create an event to the database
create participants
do an action based on the participants in the event (would happen in the event controller)
right now the way I have structured this is:
Send an axios post to create the event (EventController)
then send an axios post to create participants (ParticipantController)
then send another axios post to the event controller to do the last action (EventController)
this to me feels like way too many axios post calls, but I don't want to just put everything in one controller. Is there a better way to do what I am wanting to do while minimizing the number of axios calls?
if you need to create participants and perform particular action after event create then you can use laravel observers you can use it's created function to perform any action like after createing an event you have to make some enteries on participant table so you can perform those actions in that observer function.
I'm developing an invoicing system in order to collect payments from customers. Once I create an invoice, an email including invoice details will be sent to the customers with payment link. I want to re-generate payment token(once it expires) and send renewed payment link to the customers, and want to automate the process.
I created a Job called renewingInvoiceLinks and inside the handle method, I wrote code to retrieve all invoices with expired links and create new token and send new link. In App->Console->Kernel.php scheduled the job as following. I referred Laravel Docs but did not get the flow properly to dispatch the Job.
protected function schedule(Schedule $schedule)
{
$schedule->job(new renewingInvoiceLinks, 'renewingInvoiceLinks')->daily();
}
Things I want to get clear.
Whether using Job to do the requirement is correct or not? If not what is the perfect way to do it.
How to dispatch the Job? (Where I need to call the dispatch method?)
I think the question is quite subjective and opinionated, but here is how I'd do it:
Whenever the payment link is updated, I would fire a custom PaymentLinkUpdated event. You can either fire this event in the place(s) where you update the link, or you listen for the saving event on the affected model and fire the PaymentLinkUpdated event only when the original value is different from the updated one.
A custom event listener will listen for the update of payment links and will send out the email containing the payment details and link. This event listener should be a queued one so that emails are sent in the background and do not block the UI.
A scheduled job will check for expired payment links and will update the affected records, casting a PaymentLinkUpdated event where necessary. This will trigger step 2 (which is automatically queued again).
This way, you'd have all the logic implemented only once and sending mails would not be duplicated. If you have to send a different mail when the payment link is renewed, you can either do so in the event listener or you have to change your strategy entirely.
I am looking for information on how to pass a custom variable (transaction_logID) to the square API and then have it returned back to me on the webhooks notification URL response.
How can i specifically link a "charge" event with a "notification" event so that I can update my personal SQL record with the transaction result? (Approved, Declined etc)
Thanks for your help.
Unfortunately passing in custom data and getting it back in a webhook isn't possible.
Depending on what exactly you want to link your notification to, you can look up the ID from the webhook in the v1 payments endpoints.
I am building an MVC application (using the Zend Framework).
When users first register, the applicaiton sends them an email. My question is, where should I trigger this email from? The model or the controller? My thoughts are as follows:
In some ways, the model makes sense, since sending a registration email is part of my business logic. Users must click the link in the mail to validate their email address.
But by putting it in the model, I am 'encumbering' the model. The model's registerUser action is then only useful within the context of an application that needs emails sent for every registration.
Instead, by triggering the email from within the controller, my controller would be a litter 'fatter', but my model a little more 'fine grained'.
I have written an email service which actually configures and sends the email, and I think this is a good design decision. I am really just asking where I should be calling this service from.
Your thoughts are most appreciated!
According to Zend Framework's definition of MVC, you should put send the email from the controller:
Controllers...decide which view to display based on the user's request.
Models, on the other hand, contain:
...basic functionality behind a set of abstractions.
An email may be considered a "view" in that it displays information to the user. It is the controller's job to activate this "view."
In my opinion, I would want this in the model, as I would consider this an assumed process of the create user method, rather than any specific interaction with the user making the request.
In other words, since I would always want this email sent, regardless of the source of the request, I would identify this as a natural byproduct of the create user action, similar to a record being saved in a database.
You might want to look into using something like NServiceBus to queue messages to be sent to your Email Service.
This way you can have NServiceBus subscribe to an event that occurs and omit any manual firing of the email service etc.
Ultimately you want a failsafe way of ensuring your messages get to the intended people. This kind of framework will greatly help you ensure that this happens.
Alternatively you could store the emails to be sent inside your database and have your email service check the database queue every x minutes for new emails to send and omit the need for triggering the email sending.
Again, doing it this way will ensure at the least that the emails get sent. Should the network go down or some other disruption occur during the sending of each email you can simply leave them in the queue until the network comes back up.