I'm writing a service in Laravel 6.2 that will send out a push notification to different users at specified times down to the minute. Users select how many times a month, week, or day and at which times they want to be notified. I originally tried to store the index day (0-6) of the week and the UTC time stamp (16:00:00) and then run an Artisan command every minute to check which schedules were for that minute.
As far as I could tell there were two main routes I could take:
- Calculated: Store the frequency interval and date/time each reminder should occur.
- Pro: Keeps database lighter.
- Con: Heavy calculation every minute and may been an issue when the database grows.
- Long Term Storage: Capture the frequency interval and then store the actual date/times this needed to happen.
- Pro: Keeps calculations heavy.
- Con: Fills out the database tables quickly and eventually really slows queries.
Ideas and Explorations:
- Laravel Tasks - https://laravel.com/docs/6.x/scheduling
- Con: Not sure if I can make schedules dynamic enough without declaring each schedule in the Kernel.php file.
- RRule Packages - https://github.com/rlanvin/php-rrule, https://github.com/simshaun/recurr, https://packagist.org/packages/jpmurray/laravel-rrule
- Store the RRule in the DB and then dynamically schedule those tasks.
- Con: Not sure if this is efficient or best practice.
- Store the dynamic frequency of a recurring task in the DB, then figuring out a way to dynamically schedule lots of Laravel task scheduling and then if the server ever restarts to re-load those tasks as dynamic cron tasks.
- Con: Not sure if this is possible or not.
- Laravel Snooze Package - https://github.com/thomasjohnkane/snooze
- Con: Scheduling in the future looks to only occur once. I wouldn't want to chain another call upon the execution of the first. That seems inconsistent.