this way I know I broke at least the generate fn for example

Talking to the database should happen outside malli

This kind of check where the underlying data is mutable (database) you should make the check in the db most probably.

It would be possible to read all the usernames from the db and construct a malli schema that forces uniqueness at that point in time but that would be highly inefficient.

Your db probably already has a uniqueness constraint and you can catch a possible violation quite easily (outside malli).

i think what tempts me here is the standardization of error message generation and validation

of course I can let the db to throw constraint exception and catch it there

Yep, it may sound tempting. But you are not going to catch all the possible error situations of your app with malli 🙂

(at least in most apps you don’t)

of course

So maybe you can reuse the error reporting from malli with other error messages as well?

Though you can’t control error messages that are from 3rd party libraries or Clojure itself

But I guess you’re talking about errors returned by your API?

Or dev-time error reporting?

errors returned by my API indeed

so, right now, here’s what I’ve come up with:

(def SignupRequest
  [:map
   [:username [:string {:min 3, :max 100}]]
   [:email [:re {:error/message "must be a valid e-mail address."}
            #"^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+\.[a-zA-Z0-9-.]+$"]]
   [:password [:string {:min 8}]]])

(defn gen-unique-constraints [db]
  [:map
   [:email    [:fn {:error/message "is already taken."} #(email-available? db %1)]]
   [:username [:fn {:error/message "is already taken."} #(username-available? db %1)]]])

(defn is-valid-user? [db posted-user]
  (let [unique-schema  (gen-unique-constraints db)
        unique-user?   (->> posted-user (m/explain unique-schema) me/humanize)
        valid-request? (->> posted-user (m/explain SignupRequest) me/humanize)]
    (merge-with into unique-user? valid-request?)))

{:username [is already taken.], :email [must be a valid e-mail address.]}

i’ve separated the actual request from the second validation but merged the errors into one. not sure if i’m abusing here but i’m not not liking it 😄

Doesn’t seem like too bad abuse to me. 😉 You can also try your luck with malli.error namespace directly

Tommi (the author) makes everything modular and composable

I’ll take a look at that

tbh so far I’m contempt 😄

Some thoughts to consider over coffee: The DB uniqueness constraints need to be checked atomically, so unless you're doing this all within a locked DB transaction, you still need to check again during the actual DB write, catch the potential errors, and render the user error messages. So probably there is a second piece of code that does something very similar - what does the malli validation beforehand give you? This looks as if you're trying to repurpose malli into a declarative control-flow library. Once you start adding more and more logic and branching to the control flow, you may realize you want something with more control knobs and hooks than malli can provide. Just like clojure.spec was repurposed a lot for data coercion (which had lots of rough edges), I think repurposing malli for control-flow also may have some rough edges that are not immediately obvious.