What's the recommended way to modify interceptor chains globally? I want to add a datomic db and conn onto every request context

Do I just define my own defmethod interceptor-chain nil which will override the default one?

can I also set an interceptor chain on a branch of bidi routes? It looks like they can be dispatched on based on match context

Hmm, that doesn't quite work because I don't have the state at the right time

https://github.com/thegeez/clj-wiki/blob/1c7a3085920/src/edge/web_server.clj#L47-L54 looks like a better fit

@danielcompton I’m defining a standard resource for our entire app with some default interceptor(s) mixed in

Does anyone have an example for using response-for with a body? Giving it a map with a :body in the options parameter doesn't seem to make any difference

I've been trying various things based on the above snippet, but as long as the resource has a parameter I get the result in the bottom of the snippet

newbie here, is there anything wrong with this?

(ns grafana-annotation-server.core
  (:require [yada.yada :as yada]))

(def routes
  ["/" (yada/handler
        {:methods
         {:get
          {:produces "text/html"
           :response "<h1>Hello World!</h1>"}}})
   ["hello" (yada/handler
             {:methods
              {:get
               {:produces "text/html"
                :response "<h1>Hello World!</h1>"}}})]])

(defonce server (yada/listener @#'routes {:port 7788}))

I get:

java.lang.IllegalArgumentException: cannot treat nil as HTTP response for request to ''
	at aleph.http.server$invalid_value_response.invokeStatic(server.clj:132)
	at aleph.http.server$invalid_value_response.invoke(server.clj:129)
	at aleph.http.server$handle_request$fn__24288$fn__24289.invoke(server.clj:185)
	at manifold.deferred$eval12419$chain_SINGLEQUOTE____12440.invoke(deferred.clj:750)

when visiting

/ works

oh it’s probably bidi

hm, it’s actually a combination of bidi and the fact that @#' doesn’t actually refresh the routes when reloading the code

(I think!)

@runejuhl This might be a problem that response-for doesn’t include the default interceptors

@runejuhl I ran into that one and basically wrote this macro:

(defmacro with-server
  “Runs resource in server and defines url for use in body”
  [resource & body]
  `(let [resource# ~resource
         vmodel# (vhosts-model [:* [“/api/foo” resource#]])
         listener# (y/listener vmodel#)
         port# (:port listener#)
         close# (:close listener#)
         ~‘url (str “:” port# “/api/foo”)]
     ~@body
     (close#)))

to get a more realistic scenario

Then call like (with-server (your-yada-resource) (clj-http/request {:url url}) (not sure what the call with clj-http looks like)

@stathissideris I've done something like the following in similar situations when I was unsure where the error was:

(bidi.bidi/match-route ["/" [["" :asd]
                                   ["stuff" :thingie]]] "/stuff")

@borkdude that makes sense, thanks a lot!

@runejuhl thanks, I know this technique, but didn’t think to employ it here. I think I’ll go with the bidi verbose syntax, the terse one has always been a problem for me

what about reloading code? @#' doesn’t seem to work

I always get the old routes

this doesn’t work either:

(ns grafana-annotation-server.core
  (:require [yada.yada :as yada]))

(def root-handler
  (yada/handler "OK"))

(def hello-handler
  (yada/handler
   {:methods
    {:get
     {:produces "text/html"
      :response "<h1>Hello World!</h1>"}}}))

(def routes
  ["/"
   [["" @#'root-handler]
    ["hello" @#'hello-handler]]])

(defonce server (yada/listener routes {:port 9999}))

maybe component is the only way to reload

I don't think you want to be dereffing there

(disclosure: @stathissideris wrote bidi's verbose syntax!)

@runejuhl that looks like a bug with response-for. I'll investigate

@malcolmsparks even better 🙂 thank you -- and thank you for yada!

@stathissideris and others. As of this morning, bidi properly supports vars. Upgrade.

bidi 2.1.0

Need to announce later tonight

@dominicm is correct. Derefs are pointless because you're only then providing a value. You must use the actual ref (with bidi 2.1.0) to get new vars without a full reset. Sorry, just noticed this issue on the bus this morning!

@malcolmsparks that’s very convenient, thanks!

@stathissideris that aleph error is an all-too-common one I'm afraid. It basically means bidi fails to match and nil is passed to aleph.

Backstop with [true ..] which avoids a passthrough. True always matches.

[true (yada nil)] produces a 404 to avoid a 500

@stathissideris Bidi!!!!10101

@malcolmsparks as you can see I’ll do anything to avoid using component 😄

@stathissideris Right. And bidi and yada are component agnostic :)

@stathissideris let me know if bidi 2.1.0 fixes your issue or not

it did!

(ns grafana-annotation-server.core
  (:require [yada.yada :as yada]))

(def root-handler
  (yada/handler "OK"))

(def hello-handler
  (yada/handler
   {:methods
    {:get
     {:produces "text/html"
      :response "<h1>Hello World!</h1>"}}}))

(def routes
  ["/"
   [["" #'root-handler]
    ["hello" #'hello-handler]]
   [true (yada nil)]])

(defonce server (yada/listener routes {:port 9999}))

Vars ftw!

this is the code that plays well with reloading

I’ve been looking for an excuse to learn yada properly and today the need arose to write a tiny server to feed grafana with “annotations”

to get vertical lines in the graphs

I have a yada endpoint that works fine (returns JSON) when doing: curl 127.0.0.1:10000/api/endpoint or curl localhost:10000/api/endpoint But behind nginx, I get a 404:

Not found

(mostly I don't know where to start putting logs)