Fork me on GitHub
#clojure-spec
<
2019-04-23
>
robertfw20:04:02

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?

seancorfield21:04:39

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

👍 1
robertfw21:04:32

this looks to work nicely 🙂 thanks

didibus05:04:22

Wow didn't know that

seancorfield21:04:27

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

robertfw21:04:34

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

seancorfield21:04:11

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

robertfw21:04:21

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

robertfw21:04:14

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

robertfw21:04:35

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

alexmiller21:04:26

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

robertfw21:04:50

prayers: answered

robertfw21:04:39

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

seancorfield21:04:26

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

robertfw21:04:53

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

alexmiller21:04:24

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

seancorfield21:04:21

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

alexmiller21:04:38

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

👍 1
robertfw21:04:16

that's what i suspected. thanks 🙂

alexmiller21:04:29

we have a list of 10 areas of work for spec2

alexmiller22:04:19

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

seancorfield22:04:41

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 🙂 )

alexmiller22:04:36

you mean rework between now and "the end" ?

seancorfield22:04:16

Between now and non-alpha status.

alexmiller22:04:38

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

seancorfield22:04:47

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

eggsyntax22:04:12

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