this ctx has environment control, to determine which implementation to use (test,prod,dev)
If this is the problem you’re trying to solve, we typically address this with environment variables that influence things like database connection strings so that dev, test, and prod can work on different data.
Personally, I would recommend against environment variables for of configuration. There are a number of notable platforms including Kubernetes that promote the use of environment variables for this, probably because it’s the easiest way of injecting data into a container in a language-neutral fashion. However, this makes the behaviour anything but platform-neutral, which is harder to notice and a somewhat worse problem!
Is an env variable a mapping from an upper-case UTF8 string ‘KEY’ to a arbitrary UTF8 string value? No; neither the case nor character encoding is specified.
Is an env variable a mapping from an arbitrary string key to an arbitrary string value? Yes, but also no; POSIX actually defines this:
These strings have the form name=value; names shall not contain the character
…but it’s up to the individual applications to parse it themselves:
The array is pointed to by the external variable environ, which is defined as:
extern char **environ;
Soooo… Is an env variable just a string? Well, POSIX says so, but that’s assuming applications follow POSIX, and there’s nothing inherently ‘stringy’ about the
extern char **environ; anyway. Add unusual character encodings, niche string substitution commands or exotic control sequences though, and things start to fall apart quickly. Give me an application that reads environment variables, and I’ll be able to give it garbage data that is literally invisible to the poor programmer trying to work out why it doesn’t work!
In practice, this is not often an issue, as programmers typically follow convention and choose sensible key names and values, and a somewhat POSIX-compliant environment is generally assumed. That said, I don’t think many users of environment variables realise how many opportunities there are for the data to get garbled between, say, their Kubernetes ConfigMap and their application. It only takes one weird design choice or oversight in a shell’s implementation to invisibly mangle your environment variables, and there can be many shells in a seemingly simple container, from a behemoth like GNU Bash to the most naive ‘exec’ function in a language’s standard library.
That’s a long way of explaining why I fully support using ‘contexts’ in application code directly to specify differences in behaviour for development, testing or production systems: they’re easy to instantiate directly in a REPL, and the application can read them from a nicely-defined JSON (or even better, CBOR) file, skipping any chance of interference by a shell