Identify command from Application instance

[danpalmer]

Problem

I've got some startup work to do¹ that only makes sense to do for some of the commands the application is being run with.

For example: I may want to load a data file to be served when running serve, but this doesn't make sense to do when running routes or `migrate, and it can cause problems if done then².

Solution

1. Add a way to identify the command being run, accessible from the Application instance.
2. Re-work the lifecycle handlers to provide more correct coverage of the lifecycle (like this? I think the lifecycle is currently incorrect, or at least I didn't expect it to work like this?).

A rough implementation for (1) would be to parse the command line arguments and persist the command-to-be-run as a value on the Application that lifecycle handlers could check.

Alternatives considered

Enabling/disabling different functionality with environment variables

A reasonable temporary workaround, but not suitable for publication. This adds more state space that must be accounted for in configuration, more options that must be documented, and easy foot-guns for causing issues.

Adding additional commands that do the right thing

Commands can be overridden so this works, however it means duplicating a bunch of implementation work than Vapor has already done.

Checking "raw" command line arguments

Either via ProcessInfo or the application environment arguments. This works, and is probably the best of the alternative options, but it means implementing a separate parser for those arguments that must line up correctly. This logic could diverge in the future.

Footnotes

1. Enabling external error reporting, pushing metrics externally, connecting to a database that's not available locally, loading a large data file to be served, enqueueing jobs that should only be done when serving, I'm sure there are more. ↩

2. Problems like code erroring and crashing the process because environment variables aren't set (Imperial does this), starting queue jobs that might get killed half way through when the short-lived task completes, and general unexpected behaviour. ↩

[jhoughjr]

I actually ran into this issue when I wanted to make commands to configure PMCE on the websocket my vapor apps started so I could orchestrate integration tests easily. I think that relates to the life cycle interaction issues you might have had.
I agree for sure with 1 , will have to ponder 2.