Live data from Hacker News

The Twelve-Factor App (2025)

12factor.net

11–20 of 184 posts

Re: The Twelve-Factor App (2025)

#12

I can't believe how old this is and I feel like most devs still haven't internalized this which is a shame.

Is it devs that haven't internalized this? Or management? Because I'd love to do this, but I always report to people who demand that everything be done in "a few days".

Re: The Twelve-Factor App (2025)

#13
Every time it gets posted I read through the list and think "export services via port binding… of course a web server binds to a port, of course it‘s decoupled that way, what else would you do" and "treat backing services as attached resources… huh, is that really only about not linking in a database, but connecting using a JDBC string, for example?"

So let me ask for once: what am I missing? Why is that interesting and not trite?

Re: The Twelve-Factor App (2025)

#15

I really thought this would be a 12 layer MFA demo showing the absurdity of our current painful & unsustainable MFA trends.

Every time I leave my phone in the other room to “finally get some work done”, please enter this goddamn number we sent to your SMS, and I close my laptop.

Re: The Twelve-Factor App (2025)

#16
Still incredibly relevant. Even if you don’t apply it, there is so much to learn by reading this in 15 minutes.

The only grievance I have with this is Chapter 3: Config [1] “Store config in the environment”, “Credentials to external services such as Amazon S3 or Twitter”

Besides being bad advice, this had the second-order effect of leading devs to believe they could put all their local env secrets in ~/.bashrc files.

Stop doing this. Do the other 11.5 factors.

[1]: https://12factor.net/config

Re: The Twelve-Factor App (2025)

#17
post #13

Every time it gets posted I read through the list and think "export services via port binding… of course a web server binds to a port, of course it‘s decoupled that way, what else would you do" and "treat backing services as attached resources… huh, is that really only about not linking in a database, but connecting using a JDBC string, for example?" So let me ask for once: what am I missing? Why is that interesting…

I think backing services as attached resources was opposed to the practice of having your DB, and cache, and whatnot managed and maintained by a completely separate team and not really treated as part of the application. Even the schema changes.

The port binding was really a response to tomcat or modphp being modules in the webserver, as opposed to hosting their own web service internally. This was before nginx took off, and proxying to internal application ports was common.

edit:

I was wrong about the backing services, it seems it is really about treating them as configurations and being able to swap them out without making code changes.

https://12factor.net/backing-services

Re: The Twelve-Factor App (2025)

#18
post #11

Heroku seemed like it was going to be the future back then. Every time I find myself struggling to understand some nonsense in Azure I dream of the simpler future we lost.

Fly.io brings back some of that easy of deploy.

Yep, agreed. Fly.io is the closest to Heroku that I’ve found.

Re: The Twelve-Factor App (2025)

#20
post #13

Every time it gets posted I read through the list and think "export services via port binding… of course a web server binds to a port, of course it‘s decoupled that way, what else would you do" and "treat backing services as attached resources… huh, is that really only about not linking in a database, but connecting using a JDBC string, for example?" So let me ask for once: what am I missing? Why is that interesting…

I think you gotta look back to how web servers worked before containers.
Post reply on HN