Clojurians Log v2

I see what you mean, I also don’t really use spec for html form validation

but you could make a form spec, that adds restrictions to a map spec

but when integrating with external data sources, I start with specs to model how the data will be represent as clj data

There's also the fact that spec shouldn't be used on endpoints, because of the open key nature, I essentially get to run arbitrary validations against endpoints.

Spec is great for "internal" use: functions etc. It's not a general purpose data validation metadata language.

right - and that's what I want from schema I think

I don't think schema handles the password-confirm case particularly well either, but that's for other reasons. It can with a little bit of fiddling.

I think clojure is missing a great library which handles the user-facing part of validation/errors imo. There's some good ones, but there's cases they choose not to handle.

It's a hard problem to solve of course, so I'm not surprised at all.

for a previous project I had to provide human readable invalidation messages for large maps and schema wasn't too bad bc it quickly became clear what the problem fields were in general & then you could provide specific overrides

but then that is hacky

https://github.com/logaan/vlad does a great job of this

I guess I like being able to type and validate my interfaces in a granular way & schema feels more like that tool

why wouldn’t you use spec on endpoints… I take it everyone has seen Rich’s spec-ulation talk

I have. It's not secure. You shouldn't do it.

mmm vlad looks nice

Because of the open key nature, let's say there's a bug/feature in LibraryA's specs, where it takes 1s/character of input, or something exponential perhaps. This is fine normally as the inputs are usually only 1/2 characters long. However, Eve can come along and send you a map like:

{:user/login "eve"
 :libraryA/slow-spec "GOTCHAGOTCHAGOTCHA"} ;; pretend this is 4096 chars, or some other upper limit

thanks for the link

ok, I see that it has a potential DDoS attack surface, if you have loaded namespaces w/ buggy specs

not a deal breaker imo, unless you have crazy side-effecting specs

Bug they don't have to be in my library, just in an older transitive library one of my dependencies use. I don't think it's unrealistic to have slow specs at all. Some of them may necessarily be slow.

I get that, still not that big a deal imo

@dominicm I also remain unconvinced 🙂

have you raised this concern in a slightly more public forum?

It was raised with Alex a while back. The response was to validate data before passing it to spec.

right, that's interesting because it seems the promise of spec is validation

(or, one of the main ones as well)

but not for user-input, it's for data inside a system really.

select-keys would be enough, right?

Yep. But you're violating the principles of spec there. 😉