I'm saying that, the one thing I know about looks like obvious nonsense -- "write your logs to stdout and let someone else sort it out" -- so I assume the rest of it is equally facile and silly.
So now, when I see a reference to "12 factor app" I assume "ah, a hello world app from someone who's going to leave and let someone else figure out how to make it work in the real world at real loads with real regulatory or compliance needs"
In other words, for me, it's a shibboleth for "toy" or "unserious piece of shit"
There may, in fact, be parts of the guidance that aren't deeply incorrect. But anyone who points at it as a way to do things, without caveats, is suspect.
It's not 'someone else'. It's whatever environment the application ends up running in.
The idea of 12 factor is to define a reasonable interface for your application. The environment doesn't need to worry about providing interfaces to logging services or collecting files from a custom directory, or making sure the application isn't going to fill the disk with log output - if the app is 12 factor, the only thing the environment needs to do is collect stdout.
As a 12 factor app, write such that what you put on stdout is useful for that purpose.
As a system hosting 12 factor apps, collect stdout and put it somewhere useful.
As a developer of a 12 factor app, when you want to see your log output, go wherever the environment puts it and look there.
That's a useful contract that works at scale. Not sure why you think it doesn't.
So now, when I see a reference to "12 factor app" I assume "ah, a hello world app from someone who's going to leave and let someone else figure out how to make it work in the real world at real loads with real regulatory or compliance needs"
In other words, for me, it's a shibboleth for "toy" or "unserious piece of shit"
There may, in fact, be parts of the guidance that aren't deeply incorrect. But anyone who points at it as a way to do things, without caveats, is suspect.