so I got the point where I think I am not using yada in the right way...I am basically wrapping my computations so that it does not throw because I want to have control over the returned payload in case of exception..but...I feel I can ask yada to customize this...for instance, I do:

(instance? PSQLException res) {:status 400
                                   :message (str/trim (first (or (re-find #"Detail:(.*)" (.getMessage res))
                                                                 (re-find #"ERROR:(.*)" (.getMessage res)))))
                                   :error {:code -32603}}

this way I don't need to use try...`catch`

(btw up there is JSON-RPC 2.0)

@richiardiandrea You are using an 'escape hatch' which is ok. You are determining the status code is 400 is there is a PSQLException. That is not something that yada can figure out by itself. You should catch Exceptions that you can handle. If you let them through yada will see uncaught exceptions as 500. If you are sure 400 is the appropriate code in your case, you're doing this right. I would normally question whether all PSQLExceptions are the client's fault, but it's your app.

@tangrammer: logging the response body is possible if you make it a string or byte-array. But if it's a stream or nio channel you can't.

@malcolmsparks: at last i used this approach for logging middleware

(defn log-handler  [ctx]
  (if  (>= (-> ctx :response :status) 400)
    (let [body (bs/to-string (-> ctx :response :body ))]
      (log/info "CALL >>  "  (:response ctx) " :: " (-> ctx :request :uri) " :::: " (-> ctx :parameters) " :: " body)
      (assoc-in ctx [:response :body] (bs/convert body java.nio.ByteBuffer)))
    (log/info "CALL >>  "  (:response ctx) " :: " (-> ctx :request :uri) " :::: " (-> ctx :parameters))))


resource=> {...
 :logger log-handler
...}

@tangrammer: looks good to me

🙂 it's a naive approach due that it doesn't consider special body types but is a starting point

You have to be careful logging large bodies. If you have a slow consumer, parts of the body could be sent at different times. When exactly should you log? At the start? At the end? I think the only compromise is to log metadata but not the body itself, unless it's a string. Coercing a body to a string could be very expensive. Try doing that with a video file boxset of Game of Thrones....

Now that clojure.spec is announced, are there plans to support it in yada?

Yes. It's a great excuse for yada 2.0 ;)

But I'm holding off until Clojure 1.9 is out because yada is a heavy user of schema and spec needs the coercers (conformers)

have you heard anything about the possibility of coercers for spec?

that's one of the reasons I'm holding off as well

I think they are conformers, but yes it's early days - I don't want to be an early adopter!

🙂 well, I'm an early adopter I think

RE conformers, Alex M(iller has been cautioning against them. They are fairly simple to add onto spec though, there is a gist demo'ing a working implementation.

@dominicm: what was his reasoning against conformers ?

@mccraigmccraig: Perhaps I am misremembering, I can't find the comment now. But I did dig up the code in my process https://gist.github.com/gtrak/9b6d16d0423b284292dbbdd095bf91e9

clojure.spec can do runtime validation, but in my opinion, it's not well catered for.

hmm doesn't that defeat its purpose?

@imre The case for spec is strongly towards function specifications during development only

There is a comment by Rich that you can use valid? to do it explicitly, but in my opinion, it's design doesn't suit that particularly well.

hmm... I can see that as a serious blocker of adoption of spec

runtime validation and detailed validation failure reporting are needed in a lot of business cases, if I cannot use spec properly for that, why should I double the dev and maintenance effort and write the same thing in spec and schema for example?

@imre: I agree. I've been working on a library in this space, and been thinking about it in general, for some time. Spec isn't general enough for me, I think this comes about from it's insistence on encouraging some use-cases of spec to be done in a more "clojure-y" way.

hmm clojure-y might mean good and bad

being more functional is good

data over functions is good

repl-driven dev over tdd is not (heresy!)

at least in my opinion

I agree with the points here. Lisp loves runtime. Everything else is catering to other languages' weaknesses.