Messenger Consume or other CLI Jobs

[alexander-schranz]

Is there anything shipped with FrankenPHP to configure to automatically also running the bin/console messenger:consume command?

On current hostings we use supervisor to manage this. But thought maybe frankenphp has something build in to configure the messenger consume command as part of frankenphp and so I only reload/restart frankenphp on deploy?

[dunglas]

You can use https://github.com/Baldinof/caddy-supervisor to achieve that.

See also #490

[alexander-schranz]

Thx. /cc @wachterjohannes @chirimoya

[AlliBalliBaba]

@dunglas I have an old experimental branch that uses https://github.com/go-co-op/gocron to run cron jobs or cli-worker scripts via frankenphp with a configuration that looks something like this:

frankenphp {
	cli {
	        script artisan schedule:run
	        crontab  1 * * * * *
		enabled true
	        overlapping true
		output on
	}
}

While it feels weird to have this in a web server configuration, most PHP applications need some variation of scheduled jobs and it's often very annoying to set up. Could you see something like this being added to FrankenPHP?

[dunglas]

I would prefer keep to kind of features as plug-ins. However, having official documentation entries for this kind of things could be nice!

[withinboredom]

Generally, I wouldn't want to run these types of things on the same servers that is serving web requests. Reasons mostly include:

• CPU usage of jobs would impact the performance of requests
• if the job crashes the process, all requests will be lost as well
• generally, jobs require more memory than requests, and devs tend to accidentally overcommit resources, which can lead to OOMing the requests being served.

I would recommend performing cron/jobs on the same server as a generic anti-pattern.

[AlliBalliBaba]

I agree that bigger projects need to separate these concerns and have an accordingly more complex architecture. Something like this would just be SO convenient for smaller projects that want to efficiently use the available CPU cores and have minimal configuration. I guess I'm just remembering the first time I had to set up scheduled jobs and how unnecessarily complicated it was 😅.

[withinboredom]

Totally agree, to a point. The issue is that if you make doing the wrong thing easy, people will do it more often, and then complain that it's your fault when it blows up (see: PHP haters). That being said, if we make it obvious in the docs that it is for dev-purposes and/or low-traffic sites, it's probably a great idea (as long we KISS it -- otherwise, the next thing people will be asking for is an admin api to manually trigger jobs).