Fork me on GitHub

There's some broken examples and some doc issues but I'm working hard to fix them. Expect a lot of improvement soon


The code is now solid and stable, since March I've been working on using yada 1.1 in some juxt projects and it's only needed a few minor tweaks. Once the docs are in better shape I'll push forward to fill in the gaps (range requests, partials, reactive negotiation).


But any problems please let me know. I'm mostly in 'support' mode rather than 'dev' mode for the time being.


Is yada 1.0 suitable for use in production then if work on 1.1 was started a few months ago already?


(It sounds like it is, I’d just like to make sure.)


Any plans for clojure.spec support in yada? 🙂


The examples <> refer to names String, Long, etc. but there is no require for them. I’m assuming these are schema.core.String etc.?


@jonathanj: I think that yada is currently in a lot of productions projects (I can add 2 to this list) and regarding clojure.spec following previous comments of Malcolm , he doesn't want to be an earlier adopter but he is very attracted of clojure.spec 🙂


String , Long... maps directly to java ones


@jonathanj: i've had 1.1 in production for a while with no problems. i wouldn't advise using 1.0 - it works fine, but there were significant API changes and features additions in 1.1


@mccraigmccraig: Thanks, that’s good advice. Is there an overview of the API changes?


I’d like to get an idea of how differently the examples might apply.


no overview that i know of... you could get older versions of the docs from the repo ?


@jonathanj: the 'API' has changed rather a lot because 1.0 was based on both maps and protocols whereas in 1.1 it is just maps. How painful it will be to upgrade depends on how many resources you have made with 1.0, but concepts are broadly the same (e.g. content negotiation, conditional requests).


1.0 was released last September, 1.1 was released last March. I don't plan any overhauls in the near future, although spec. is on the horizon


I might add support for spec. for parameter validation once Clojure 1.9 comes out. The more significant use of schema in yada is for validating resource maps to protect users from making mistakes (which would cause runtime errors). That's a useful role for schema and changing it to spec would not add much value so I'll probably do that much later


Spec also lacks coercions. Which I think yada uses to know what you expect in your handler.


(s/conform integer? "1") ;; => :clojure.spec/invalid You would have to use a :yada/integer where yada would have an internal registry of coercions. Or perhaps a coercion library will surface for spec.


Is anyone modifying interceptor chains in their yada handlers? Just asking because I've made these first-class in the resource model and provided some helper functions to manipulate them. This could break your code if you're depending on yada.handler/default-interceptor-chain - only stuff in yada.yada is considered 'public API' but I know there's a strong chance the latest release (1.1.18) will affect some of you - be fore-warned and allocate some extra time if you're upgrading


Apologies for this breakage - I can add an alias if it helps. Otherwise, I think this is useful improvement for those who need to mess around with yada's internal workings


@malcolmsparks: we modify interceptor chains... but we just inject a new interceptor into the (:interceptor-chain resource) iirc, so we should be ok, right ?


That will still work.


The security markdown page in the manual says “Coming soon” under “JWT authentication”, does that mean the documentation is coming soon or the functionality?


@jonathanj: JWT is done. Documentation is coming soon (tm)


yes, @dominicm is correct - JWT is done, so is OAuth2 that uses it (just Google and Github right now)


rather, Google and Github are built in (as kind of examples) - it's fairly trivial for anyone to implement support for a different authorization provider