Fork me on GitHub
#clojure-spec
<
2018-12-06
>
borkdude17:12:21

what would be a good name for a lib with some testing utils around specs? mostly things like instrumenting and unstrumenting in the scope of a body kind of macros, cross platform. my gut feeling says that spec-test will be too confusing

shaun-mahood17:12:59

Pretty sure checkulative should be a word

Marc O'Morain21:12:14

chickity check yo self

Marc O'Morain21:12:13

Chickity-check your specs before you wreck your specs.

taylor17:12:54

spec-too-the-speckoning

😂 12
Alex Miller (Clojure team)17:12:13

I actually wrote a with-instrument at one point, not sure if I put it in a ticket or not

borkdude18:12:46

this one also works with clojurescript

lilactown19:12:55

I'm having a silly thought: clojure-spec-as-a-service. We have a few different clients in our system, some of which are Clojure(Script) and some aren't. For those that aren't, exposing common specs for our domain is a bit more troublesome then distributing a library. One solution might be to create a service that accepts (data, spec-name) and responds with true/`false` if it conforms. Could also do generation of fake data that conforms. Anyone done this before? I'm not sure if this is a good idea yet, architecturally

noisesmith19:12:34

@lilactown I'd be tempted to copy the way kafka works with avro - the schema is versioned and serialized and there's a rest endpoint to look up the schema, then you can deserialize, cache and reuse it

noisesmith19:12:58

and naturally you can use post to add a new spec or new version of a spec, with backward compat enforcement

lilactown19:12:48

> look up the schema, then you can deserialize, cache and reuse it practically this means that I need to have a common language and engine for working with those schemas in all my clients

lilactown19:12:26

I think the problem I have right now, is "I have all these specs; how do I reuse them across my JS web & mobile clients?"

lilactown19:12:27

do I build a language on top of spec and build an engine for each platform? Do I adopt something else other than clojure.spec that I more of my clients will understand?

cjsauer19:12:01

@lilactown that's an interesting idea...would part of the spec endpoint also do format conversion? For example, would it be necessary to validate JSON data (convert it to EDN, run through spec/valid?, return result)?

lilactown19:12:46

yes, I am thinking that JSON with be the format it primarily accepts

lilactown19:12:57

so additional complexity

cjsauer19:12:01

One issue I can think of would be semantic parity between environments...JSON is sort of inherently less expressive then, say, EDN, so you'd have to be careful that they were validating "apples to apples" so to speak.

noisesmith19:12:37

transit could be useful for this - it's expressly designed for interchange (unlike EDN) and it has implementations for the bigger languages, and it can handle all the standard clojure data types

cjsauer19:12:01

Spec reuse is definitely the right idea. It seems like there'd be quite a few "translation layers" no matter how you tackled it. For example, I've spoken with people who are using Datascript as a sort of "lingua franca" of domain modeling, and then generating specs from that representation. I wonder if "specs" could be generated for other runtimes in their respective native form.

lilactown19:12:47

a lot of the data we'd be verifying would be JSON in the first place - e.g. we get a response from our GraphQL API, and then want to see if it conforms to certain rules: "Does this user data have <product> associated with them?" "Are they allowed to use <capability>?"

lilactown19:12:03

but there could be other context, unrelated to user data, of course

noisesmith19:12:01

oh - also if you are doing permission checks there's actually an advantage to checking on the central server instead of telling the client how to validate

noisesmith19:12:29

(eg. keeping changes in sync without pushing...)

lilactown19:12:01

yeah permissions isn't primarily what it would be used for but I feel it could grow out of this service organically