3.2 KiB
Kithkin
Contacts and calendars for smart people.
Scheduled jobs
Jobs are located in app/Jobs and we use Laravel Horizon as an admin frontend.
Starting jobs
To start the jobs themselves, run php artisan schedule:work. This creates a running process that outputs job runs and other minimal data.
Production cron
On production, this should be setup via cron job like this:
* * * * * /usr/bin/php /path/to/artisan schedule:run >> /dev/null 2>&1
Monitoring jobs
Horizon is the monitoring app and frontend. Run php artisan horizon to start it. This will create a running process that outputs the results of the jobs in a better format than schedule:work.
The /horizon UI is just a normal route in Kithkin; the php artisan horizon process is what actually runs the workers and updates Redis for the dashboard.
Working with scheduled jobs
To see the list of scheduled jobs and their crons, run php artisan schedule:list.
Application flow notes for my own sanity
Local calendars
Local calendar creation
Creating a local calendar (not available in the UI yet) hits the Calendar.php controller. That store() method creates entries in the calendars, calendarinstances, and calendar_meta tables using model functions for each of them.
Local event creation
When the user creates a new event, it gets added to calendarobjects where the raw VEVENT data is stored. We have our own utility tables event_meta and locations for way more metadata and convenience fields so that we don't need to keep parsing the VEVENT blob.
The controller is EventController.php and it uses models Event.php (calendarobjects), EventMeta.php (event_meta), and Location.php (locations, not yet created).
Remote calendars
Remote calendars are calendars that a user "subscribes" to via .ics URL. These are also called subscription calendars in the app.
Remote calendar creation
The user adds a new remote calendar by entering the url in calendar settings, adding a display name, and picking a color.
When a new remote calendar is added, we create a row in calendarsubscriptions, calendars, and calendarinstances, and a corresponding meta data row in calendar_meta. This is so verbose because of the way SabreDAV handles remote subscriptions.
-
Normally, all Sabre does is add a row to
calendarsubscriptions. It doesn't contemplate pulling the events down into the database locally--it assumes you're fetching the .ics file fresh and parsing out events every time the user loads the calendar. -
Since we want to be able to search everything and do more, we need to pull the events down into our database. This requires creating corresponding rows in the local calendar tables. It's a little weird Sabre-wise since we have remote calendars populating their local calendar tables, but Sabre doesn't care that these are in there and it means the user can also share them out again.
The controller is SubscriptionController.php and it uses the additional model Subscription.php.
Remote events
When a user creates an event in a subscription calendar, we need to send that back up to the primary server. We also create the event locally as normal.