You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've got some startup work to do1 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 then2.
Solution
Add a way to identify the command being run, accessible from the Application instance.
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
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. ↩
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. ↩
The text was updated successfully, but these errors were encountered:
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.
Problem
I've got some startup work to do1 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 runningroutes
or `migrate, and it can cause problems if done then2.Solution
Application
instance.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
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. ↩
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. ↩
The text was updated successfully, but these errors were encountered: