This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-03-20
Channels
- # bangalore-clj (1)
- # beginners (145)
- # boot (8)
- # braid-chat (2)
- # capetown (2)
- # cider (27)
- # cljs-dev (232)
- # cljsrn (30)
- # clojure (223)
- # clojure-boston (1)
- # clojure-dusseldorf (2)
- # clojure-greece (1)
- # clojure-italy (21)
- # clojure-russia (16)
- # clojure-sanfrancisco (13)
- # clojure-spec (33)
- # clojure-uk (56)
- # clojurescript (165)
- # core-async (16)
- # core-logic (5)
- # cursive (14)
- # data-science (2)
- # datavis (2)
- # datomic (49)
- # duct (15)
- # editors (5)
- # emacs (6)
- # fulcro (11)
- # graphql (11)
- # hoplon (8)
- # jobs (4)
- # jobs-discuss (82)
- # jobs-rus (7)
- # leiningen (4)
- # luminus (5)
- # off-topic (90)
- # om (7)
- # om-next (1)
- # parinfer (67)
- # pedestal (34)
- # portkey (46)
- # re-frame (12)
- # reagent (4)
- # reitit (3)
- # remote-jobs (1)
- # ring-swagger (8)
- # shadow-cljs (13)
- # spacemacs (18)
- # specter (6)
- # sql (5)
- # tools-deps (4)
- # unrepl (40)
- # yada (26)
for some reason remembered this https://juxt.pro/blog/posts/data-macros.html
funnily enough at the AWS build day I'd asked about out of the box support for exposing CLJ(s) routes via SAM since conceptually it was so close to how you might use integrant to expose something
they were obv like 'lol do it yourself' though haha
@dominicm are you still using schema primarily, or are you migrating toward spec?
sorry, bit offtopic but related to that post
@alex.lynham It varies. Some are excited and throwing it all away for the one true spec. I'm quite sceptical, so I'm using it in some places, but not others.
I've recently done some stuff with spec and I found it uglier and harder to get useful outputs quickly... but then I'm not sure how much of that is familiarity
sort of feel like schema is simpler, but again...
yeah I was playing around with them for validation & data generation and it felt harder than the schema equivalent
that sounds like a very weird statement to me as I exclusively use spec for data (and am very lazy with fdef
s)
@alex.lynham moving this to a thread so it's not so spammy in portkey 😛
@U11SJ6Q0K the problem I have is things like forms, how do you validate password-confirm
? You need the whole map to validate that it is =
, but you can't say that the error is on password-confirm
.
It just doesn't work for forms where the expectations are different than the data you're validating.
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.
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
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
If I send you that, maybe across a few thousand connections, I have just performed a DOS.thanks for the link
ok, I see that it has a potential DDoS attack surface, if you have loaded namespaces w/ buggy 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.
@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)
select-keys
would be enough, right?