The Processes a Project Needs

A modern app is not one process. It is a site, a queue worker, an asset watcher and a scheduler, and the usual way to run them is four terminal tabs you forget to reopen. This chapter is about giving that job to the thing that is already supervising everything else.

The problem

You know the four tabs. One for npm run dev, one for php artisan queue:work, one for php artisan schedule:work, one to actually type in. They are unlabelled, they are in a different order on Tuesday, and when you restart your machine you remember three of them.

The bug that produces is specific and maddening: a feature that works for you and not for a colleague, or this morning and not this afternoon, because a queue worker was running then and is not now. Nothing tells you. The job is simply queued forever, and the email never arrives.

grove dev

grove dev freddy

Grove starts the project's development processes and supervises them alongside the site — same lifecycle, same logs, same place to look. Stop the site and they stop with it.

It reads what to run from the project itself, so a colleague who clones the repository gets the same processes without being told about them. That is the same idea as chapter 13, arriving early: the environment is described in the repository rather than in somebody's habits.

The one command that must not be in the list

A Laravel project may define a dev script that runs everything at once — typically through concurrently, starting php artisan serve among other things.

Do not let Grove run that one. It starts PHP's built-in development server, which then serves your site on a port, in parallel with Grove serving the same site properly. Two servers, one project. The symptoms are worth recognising because they look like a bug in your application: a change appears on one reload and not the next, sessions behave strangely, and a debugger attaches to a process that is not handling the request you are looking at.

Grove skips the entries it knows about — the all-in-one dev script and the built-in server — and says which it skipped, rather than quietly doing something confusing. Run the individual processes: the queue worker, the asset watcher, the scheduler. Let Grove be the web server, since it already is one.

Where it went wrong

grove logs
grove logs freddy

One place for the daemon's log, a site's PHP-FPM log, and the output of the dev processes above. Which matters most when a dev process has died: with four terminal tabs, a crashed queue worker is a tab you are not looking at, and the first evidence is a feature that silently does not work. Supervised, it is a line in a log you already know how to read.

What you learned

• An app is several processes, and forgotten ones fail silently — the job is queued forever and nobody is told.
• grove dev supervises them with the site, same lifecycle and same logs.
• Never let it run the all-in-one dev script — artisan serve beside Grove means two servers for one project.
• Grove skips the entries it knows about and says so, rather than quietly doing something confusing.
• One command after a restart. If it takes remembering, the environment is still in your head.