3 ms·

> but I usually just write that myself Not saying you shouldn't, but part of the point of a framework is all the things you don't have to write yourself. What

by WJW 3y ago

> but I usually just write that myself Not saying you shouldn't, but part of the point of a framework is all the things you don't have to write yourself. What I like about (say) Rails secret handling is that the secrets file is an encrypted file in the repo itself. This makes it so that you can easily check out and run different versions of the repo from different times and not have to worry about that one time you renamed an envvar or something. Secrets get version controlled together with the app. The autogenerated .gitignore even includes patterns for the key files so you have to go out of your way to check them into the repo. The downside is that merging encrypted files can be a right pain in the arse, for example when two devs added different secrets in different branches.

shortrounddev2 3y ago
I feel that web frameworks should be flexible enough that the CI/CD system can put things like secrets into files without worrying about the particular framework that's consuming them. If you don't write the secret service in the web framework, you have to write the secret manager in CI/CD to convert formats or what have you. Something I dislike about spring boot is how spring-y everything has to be.
- ElectricalUnion 3y ago
  > CI/CD system can put things like secrets into files This sounds horrible. Why does specifically your CI/CD need to know those things? This also sounds like your CI/CD system is "too smart" and your build process is "dumb pipes", what I believe to be a unsupportable, unmaintainable anti-pattern - if people can't build/test things on their own machine, things are likely not repeatable/reproducible at all and you're one CI/CD issue away from losing your project. > Something I dislike about spring boot is how spring-y everything has to be. I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done?
  - shortrounddev2 3y ago
    > This sounds horrible. Why does specifically your CI/CD need to know those things? You set it up so that production secrets are kept in that store and are only accessible by a 1 or 2 high level people. Developers don't have access to production secrets, only dev or staging, which live on their own machines and are lower security risk > if people can't build/test things on their own machine I don't see why they wouldn't be able to build/test on their own machine. You just have a different secrets store and keys than the CI/CD does > I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done? Yes I hate this. I want to be able to decide how properties are loaded, not rely on some ethereal state managed behind the scenes and not be able to see if it's loading properly. If I want to use their terrible resources/config file, I'll specify that in middleware/startup

by WJW 3y ago

shortrounddev2 3y ago

I feel that web frameworks should be flexible enough that the CI/CD system can put things like secrets into files without worrying about the particular framework that's consuming them. If you don't write the secret service in the web framework, you have to write the secret manager in CI/CD to convert formats or what have you. Something I dislike about spring boot is how spring-y everything has to be.

ElectricalUnion 3y ago
> CI/CD system can put things like secrets into files This sounds horrible. Why does specifically your CI/CD need to know those things? This also sounds like your CI/CD system is "too smart" and your build process is "dumb pipes", what I believe to be a unsupportable, unmaintainable anti-pattern - if people can't build/test things on their own machine, things are likely not repeatable/reproducible at all and you're one CI/CD issue away from losing your project. > Something I dislike about spring boot is how spring-y everything has to be. I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done?
- shortrounddev2 3y ago
  > This sounds horrible. Why does specifically your CI/CD need to know those things? You set it up so that production secrets are kept in that store and are only accessible by a 1 or 2 high level people. Developers don't have access to production secrets, only dev or staging, which live on their own machines and are lower security risk > if people can't build/test things on their own machine I don't see why they wouldn't be able to build/test on their own machine. You just have a different secrets store and keys than the CI/CD does > I thought spring "runtime config override" was just dropping a properties (admittedly awful format, latin-1 encoded to boot) file near the compiled project uberjar/war/ear and you're done? Yes I hate this. I want to be able to decide how properties are loaded, not rely on some ethereal state managed behind the scenes and not be able to see if it's loading properly. If I want to use their terrible resources/config file, I'll specify that in middleware/startup