Fork me on GitHub
#portkey
<
2018-03-20
>
viesti10:03:58

hum, like macro, kind of…

alexlynham11:03:29

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

alexlynham11:03:40

they were obv like 'lol do it yourself' though haha

dominicm13:03:41

just fwiw, I work for JUXT 😛 So yes, that's the idea.

alexlynham13:03:31

@dominicm are you still using schema primarily, or are you migrating toward spec?

alexlynham13:03:43

sorry, bit offtopic but related to that post

dominicm13:03:09

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

dominicm13:03:12

Jury is still out.

alexlynham13:03:11

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

alexlynham13:03:31

sort of feel like schema is simpler, but again...

dominicm13:03:27

spec is for functions. Using them elsewhere seems ineffective.

alexlynham13:03:21

yeah I was playing around with them for validation & data generation and it felt harder than the schema equivalent

tatut15:03:06

that sounds like a very weird statement to me as I exclusively use spec for data (and am very lazy with fdefs)

dominicm20:03:55

@alex.lynham moving this to a thread so it's not so spammy in portkey 😛

dominicm20:03:17

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

tatut07:03:54

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

tatut07:03:30

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

tatut07:03:17

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

dominicm08:03:38

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.

dominicm08:03:55

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

alexlynham08:03:52

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

dominicm08:03:56

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.

dominicm08:03:30

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.

dominicm08:03:53

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

alexlynham09:03:56

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

alexlynham09:03:03

but then that is hacky

alexlynham09:03:35

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

tatut09:03:34

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

dominicm09:03:05

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

alexlynham09:03:55

mmm vlad looks nice

dominicm09:03:58

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.

alexlynham09:03:01

thanks for the link

tatut10:03:35

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

tatut10:03:21

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

dominicm10:03:00

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.

tatut10:03:43

I get that, still not that big a deal imo

stathissideris13:03:47

@dominicm I also remain unconvinced 🙂

stathissideris13:03:17

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

dominicm13:03:40

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

alexlynham13:03:28

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

alexlynham13:03:38

(or, one of the main ones as well)

dominicm13:03:47

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

stathissideris14:03:43

select-keys would be enough, right?

dominicm14:03:58

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