This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-12-06
Channels
- # adventofcode (112)
- # announcements (6)
- # beginners (197)
- # boot (3)
- # calva (52)
- # cider (25)
- # clara (14)
- # cljdoc (6)
- # clojure (147)
- # clojure-austin (6)
- # clojure-berlin (7)
- # clojure-brasil (2)
- # clojure-europe (3)
- # clojure-india (4)
- # clojure-italy (8)
- # clojure-new-zealand (2)
- # clojure-nl (7)
- # clojure-russia (7)
- # clojure-spec (29)
- # clojure-uk (63)
- # clojurescript (103)
- # core-async (5)
- # cursive (11)
- # datomic (16)
- # devcards (1)
- # emacs (28)
- # figwheel-main (3)
- # fulcro (97)
- # graphql (4)
- # hyperfiddle (1)
- # jobs (1)
- # kaocha (3)
- # lumo (9)
- # nrepl (4)
- # off-topic (29)
- # onyx (1)
- # pathom (4)
- # pedestal (8)
- # re-frame (24)
- # reagent (1)
- # reitit (13)
- # ring-swagger (7)
- # rum (11)
- # shadow-cljs (79)
- # sql (46)
- # tools-deps (67)
- # yada (8)
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
Pretty sure checkulative should be a word
chickity check yo self
Chickity-check your specs before you wreck your specs.
these functions will be in it: https://github.com/slipset/speculative/blob/master/doc/test.md
I actually wrote a with-instrument at one point, not sure if I put it in a ticket or not
actually, there is a ticket, but not from me - https://dev.clojure.org/jira/browse/CLJ-2015
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
@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
and naturally you can use post to add a new spec or new version of a spec, with backward compat enforcement
> 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
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?"
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?
@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)?
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.
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
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.
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>?"
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
(eg. keeping changes in sync without pushing...)