Using queues for asynchronous processing is one of my favourite tricks for offloading hard work from web servers. When working with Laravel recently I was pleased to find that it supports beanstalkd out of the box. I’ve got opinions about frameworks with Opinions but I did find one thing I really liked in the way Laravel uses queues: the sync queue option that runs your queue synchronously on your development platform so you can develop and debug your work, then switch the queue platform you use later.

It’s quite tricky to debug Laravel “Jobs” as they call the worker code – if errors occur, they don’t show up in the general output. You can use error_log() and see that output, but if there’s a PHP error, you won’t see that error. However you can configure the QUEUE_CONNECTION in .env to be "sync". The sync queue type is not asynchronous at all – instead of putting the job onto your chosen queue backend, it goes right ahead and processes the job in the current thread of execution. This completely defeats the object of using a queue but is a brilliant approach for debugging how the data passes from the dispatching context (where the data is put into the job and onto a queue) to the worker context (where the job comes back off the queue and actually gets processed) and how the job is processed.

For development use, it’s a nice feature, but do take care to enable your “real” queue configuration when deploying to a production environment so that you get the advantage of the queues. There are some good queueing services available for your cloud applications – specifically for Laravel, look at Laravel Horizon which is Redis with nicer dashboards attached :)