What about the database side of things?

If you don't need something as low-level as next.jdbc, HugSQL is my preferred library. It lets you write queries in .sql files, and the queries are then loaded as functions. If you want to dynamically generate queries, there are also libraries like HoneySQL.

next.jdbc is the go-to library to interact with SQL databases. https://cljdoc.org/d/com.github.seancorfield/next.jdbc/1.3.8...

Probably worth mentioning that triplestores/Datomic-like databases are relatively mainstream in Clojure: https://github.com/simongray/clojure-graph-resources#datalog

> I'm not sure a single "framework" would work for everyone.

I guess you weren't lying because that is not what a web framework is.

If it works for just me, that's a web framework. The fact that there are so many web frameworks shows that none work for everyone.

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

Most of these are handled by reitit and ring

Some more standard components I would no longer want to do without in a full-featured framework:

- 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

Secret handling has been abstracted away from the framework for everything I worked on; usually our deployment system would mount secrets as a file system and then you read them as a file of key->value pairs. That, or they were just set as environment variables. I guess the framework could provide a standardized secret service, but I usually just write that myself

> 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.

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.

> 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?

> 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

I think routing makes the minimal viable "framework" -- look at the many systems like Sinatra, JAX-RS, aiohttp, etc where you write functions and supply metadata to tie URLs to functions.

For clojure, that would be biff

Oh, that's a great list — see, that's why we disagree on the utility of "web frameworks". My app does not use a routing component at all, and none of the existing solutions fit my use case. I also don't have an ORM and I don't think even having an ORM is a good idea (I'm currently working on moving to FoundationDB, where you can get extreme gains by coupling your app closely with the database, rather than talking to it through a thin straw).

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.

> User input validation — that's something I've spent the better part of several years working on

And that's why I use good frameworks.

I don't think there is a framework out there that does what I need it to do, but I'd be happy to learn — which ones did you specifically have in mind?