Unclear documentation about laravel-aws-worker HOT 4 CLOSED

1. There are at least two points – first of all, you get a single point of configuration. All scheduled tasks are in PHP code, compiled using a convenient fluent API. If you use cron.yaml – you need to duplicate the same information (which tasks and when) for AWS and non-AWS environments.

And secondly, scheduled tasks are quasi-evenly distributed among instances. AWS will fire a /worker/schedule event every minute but it will be pushed to SQS queue and processed by a single EC2/EB instance. If you put it in your cron.yaml manually, either all instances will run the same task at the same time or you will have to look for a workaround/hack to make one of the instances a 'leader'. While there are solutions for this, they look way more complicated and uglier.

2. With AWS Elastic Beanstalk, every worker has a special job queue. You could just put any job directly into the queue and one of the instances of your cloud will process that job. Scheduled tasks are kind of a wrapper for 'real' jobs.

3. My code doesn't handle jobs - your application should :) My package is an interface between AWS and Laravel (or Lumen) - that's it, nothing more. It will make your standard scheduling and queuing tools work.

from laravel-aws-worker.

I understand that it might make sense when you're trying to implement AWS + non-AWS.

I might not be fully understanding the correct way to use your code but my goal and understanding is that multiple Laravel instances should be able to send queues via SQS to a single worker(Elastic Beanstalk Worker)for processing.

If that is the case, the single worker would need to be able to "listen" for new SQS messages, which is impossible on Elastic Beanstalk worker instances. The only option that I can think of is running Artisan::call('queue:work'); continuously using cron.yaml. My understanding was that your code would provide an alternative way of listening to SQS messages.

from laravel-aws-worker.

That is correct - my code is indeed providing an alternative way. It goes in the direction of least resistance - I'm relying upon Amazon sqsd to parse the queue and deliver the jobs. Laravel will simply receive a ready-to-deserialize payload.

It's a very important detail that using this package - you are pretty much guaranteed that each task (be it a scheduled task or a queued task) will be processed by one instance only.

If you run supervisor or regular cron inside of your worker (and some people do) - you will have to manage that manually, yourself.

If you put every scheduled task in cron.yaml - you lose a little bit of readability and opportunity to test on local machine using 'php artisan schedule:run'. This part is subjective, it's a matter of taste I suppose. I just like Laravel's scheduling API more than cron.yaml syntax so I would rather compose tasks there.

PS. It's always a hybrid AWS and non-AWS environment – I doubt there are developers who run local or development environments in Elastic Beanstalk, that would be awful :)

from laravel-aws-worker.

Thanks so much for the explanation, it looks like I was a bit confused as to how SQS and EB Worker functioned together, everything seems to be working out as I expected!

from laravel-aws-worker.