Components of a web framework:
1. Routing
2. ORM
3. Auth handling
4. Request middleware
5. Templating (if your application requires it)
6. User input validation
Many other components that are escaping me right now
1. Routing
2. ORM
3. Auth handling
4. Request middleware
5. Templating (if your application requires it)
6. User input validation
Many other components that are escaping me right now
- background job system
- email sending
- translation/localisation
- a decent configuration system suitable for differentiating dev/test/staging/prod/etc, and handling both secret and non-secret values in a sane way
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.
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?
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
I don't use templating, at least not for web pages.
User input validation — that's something I've spent the better part of several years working on, but in a larger context of a toolkit for dealing with forms, tables, data presentation, filtering and sorting. I daresay the solution I have now (which uses ideas dating back to Smalltalk) is way more extensive and flexible than what every "framework" out there has.
And that's why I use good frameworks.