1

I'm creating a raffle site as a small side project. It will handle multiple raffles each with an end time. At the end of each raffle a single winner is chosen.

Are Laravel Jobs the best way to go with this? Do I just create a single forever-repeating job to check if any raffles have ended and need a winner?

If not, what would be the best way to go?

THEK
  • 740
  • 2
  • 10
  • 29

1 Answers1

1

I don't think that forever-repeating scripts are generally a good idea.

I just create a single forever-repeating job

This is almost never a good idea. It has its applications in legacy code bases but websockets and events are best considered for this job. Also, you have the benefit of using a really good framework like Laravel, so take advantage of it

Websockets
If you want people to be notified in real time in the browser.

If you have all your users subscribe to a websocket channel when they load the page, you can easily send a message to a websocket server to all subscribed clients (ie browsers) to let them know who the winner is.

Then, in your client side code (Javascript), you can parse that message to determine who the winner is and render a pop up that let's the user know.

Events
If you don't mind a bit of a delay, most definitely use events for this.

At the end of every action that might potentially end a raffle (ie, a name is chosen at random by a computer - function chooseName()). Fire an event that notifies all participants in the raffle. https://laravel.com/docs/5.2/events

NB: I've listed the above two as separate issues, but actually, the could be used together. For example, in the event that a name is chosen at random, determine if the raffle is over and notify clients via a websocket connection.

Why I wouldn't use delayed Jobs
The crux of the reason - maintainability

Imagine a scenario where something extends the time of your raffle by a week. This could've happened because a raffle was cheated on or whatever (can't really think of all the use cases in that area).

Now, your job has a set delay in place - is it really a good programming principle to have to change two things when only one scenario changed? Nope. Having something like an event in place - onRaffleEnd - explicitly looks for the occurrence of an event. Laravel doesn't care when that event happens.

Using delayed Jobs can work - it's just not a good programming use case in your scenario and limits what you're able to do in the longer run. It will force you to make more considerations when unforeseen circumstances come along as well as when you want to change things. This also decentralizes the logic related to your raffle. Whilst decoupling code is good practice, having logic sit in completely different places makes maintenance a nightmare.

Kyle O'Brien
  • 932
  • 1
  • 11
  • 28
  • Very interesting. I hadn't even thought about websockets to alert the user. That'd be very cool. Regarding the events. I'm a little worried as the site will be pretty small to start with so events may not get triggered for a while. Is there any performance issues with creating a Job for each raffle that is created using Queue::later ad giving the end time as a delay? – THEK Feb 22 '16 at 22:32
  • @THeK - I'm not sure the fact that events won't get triggered for a while justifies not using events. However, you make an interesting point around the delayed job. I will update my answer to explain why I don't think that's a good idea. – Kyle O'Brien Feb 23 '16 at 08:04