Background: I am working on a service where the domain logic exists as a library, and then the actual executable is built on a web framework as a wrapper around the domain logic library. There is no guarantee two customers run the same version of this service.
Task: I was asked to create a way to print the schema for representing a subcomponent of the domain logic.
My solution: I implemented this as a command-line flag to the service executable. I.e. if you pass
--dump-schema X when running the service, it will just dump the expected schema of X and then quit. If you don't pass any flags, it will instead print nothing but start accepting requests as usual.
Rationale: I did it this way to ensure the output of the schema dump stays in sync with what the actual service will expect when run from the same binary. Additionally, it is my personal belief that if a request to the service makes sense as a one-shot command-line invocation, then it's rarely a bad idea to allow that.
Review comments: When discussing with a senior team member, they argued that the whole command-line flag thing is a step away from how they've done things before – and might be confusing as a result. He'd prefer if there was a separate executable
dump_schema which issued the command.
Counter-argument: I can understand the argument; they're a Microsoft/Windows shop, so the CLI is not how they naturally interact with their computers. However, they're slowly moving over to a Linux/Unix environment, so that's sort of a moot point, in my opinion.
My hesitation: However, thinking about it, I realise I don't have any strong arguments as to whether either approach (CLI flag or separate executable) would be preferable. They amount to pretty much the same thing, except one multiplexes in the
main procedure, and the other in the shell.
So is there any chance you geniuses are able to contrast and compare the two approaches? Or is it truly a wash?