By-passing the UI and firing off requests manually could still be a way around our "solution".This might not be a big issue if you are deep in a JavaScript powered front-end, because that is already the case (for better or worse). We now have a dependency on JavaScript for our application to function correctly.We are now disabling UI elements, which I know my UX friends are not happy with me about.The user of the form, through some kind of dark twisted magic, is able to trigger multiple requests even though you cannot seem to replicate that behaviour, no matter how hard you try.Ī fix I often see is to disable the button in the UI once it has been activated, preventing the user from triggering requests back-to-back. This problem, in my personal experience, feels especially true for AJAX powered form submissions, but can impact traditional forms as well. If you have built web based forms and had enough people using those forms, you have likely run into the problem of duplicate form submissions. They simplify handling duplicate requests and ensure that resources stay in a good state across conflicting background jobs.
To my surprise, these two features work really well together. I had thought, on first read, that I would want to use one or the other, that is ShouldBeUnique or WithoutOverlapping. I had seen the ShouldBeUnique contract and the WithoutOverlapping middleware before, but not yet had a chance to implement and internalise their functionality. So as I do, I went over and read up on the current feature set for queues. Recently I have been hacking on some refactorings and improvements to a project's queued jobs, which is all powered by Laravel's Wicked Good Queuing System™. When focusing in on some specific functionality of an application, such as notifications or queuing, I often head over to the docs and catch up on the current state of the art for different Laravel components.
0 kommentar(er)
