Fork me on GitHub

I have a question about how people handle writing specs for an API endpoint. I'm speccing out ring request maps, and have several endpoints in the same namespace. a ring spec typically involves providing specs for :status, :params, sometimes :body. However my spec names end up being quite wordy; for example, the expected body for a successful response of a given endpoint ends up being :my.ns.endpoint-name.response.success/body. Over the course of defining several endpoints, with potentially multiple possible responses, I end up with quite a lot of typing. I've been considering either moving each endpoint spec into its own namespace, so that I can use :: shorthand, but I'm not wild about the proliferation of files that will create. My other thought is to create some macro or function to help generate these specs. Any thoughts?


@robertfrederickwarner You can create a namespace alias without needing an actual namespace file.

👍 4

this looks to work nicely 🙂 thanks


Wow didn't know that


(alias 'm  (create-ns 'ws.domain.member))
and then use ::m/whatever


ah, I did not know about alias. I had considered trying using (ns ...) but rejected it as it seemed to be pretty unidiomatic


@alexmiller has mentioned the possibility of improving alias usage but I don't think any concrete proposal has been made yet.


It would be nice if it were possible to define a map spec assigning specs to given keys; I know that seems to be going against the grain of spec but it would cut down some lines of code needed to spec out json endpoints


e.g... we get data coming in as :some_value whereas in our system it's :some-value, so there's another spec to handle the conversion


I've been digging around to see if anyone has written helpers for that but no luck

Alex Miller (Clojure team)21:04:26

spec2 has support for this for unqualified keys in s/schema


prayers: answered


Is there a rough idea of when spec2 might be "ready"?


Define "ready" 🙂 We have a branch of our codebase at work that runs on Spec2.


good question - I guess, active development finished and moving into a phase of broader community use, similar to where spec.alpha is now

Alex Miller (Clojure team)21:04:24

I would say it's likely on order of months given the set of work we have talked about


Could you give us an overview of what additional work on Spec2 is still in the pipeline?

Alex Miller (Clojure team)21:04:38

hard to say whether that's 2 months or 6 but certainly I would love have it before the conj

👍 4

that's what i suspected. thanks 🙂

Alex Miller (Clojure team)21:04:29

we have a list of 10 areas of work for spec2

Alex Miller (Clojure team)22:04:19

some of those we'd like to work through before "release" and re-integration, some could be add-ons later


I'd like to cut our project at work over to Spec2 but I don't know how much rework to expect (I mean, I'm used to some level of rework given how often we rely on Clojure alphas 🙂 )

Alex Miller (Clojure team)22:04:36

you mean rework between now and "the end" ?


Between now and non-alpha status.

Alex Miller (Clojure team)22:04:38

well, I wouldn't recommend that yet but I'm not expecting that the existing apis are going to change much


Although we're heavily reliant on Spec1 Alpha in production so I don't know why I'm all that worried...


@alexmiller don't know if you already saw it, but there are a few more ideas above on s/closed.