Fork me on GitHub
#yada
<
2017-05-09
>
danielcompton04:05:10

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

danielcompton04:05:49

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

danielcompton04:05:51

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

danielcompton04:05:36

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

borkdude09:05:58

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

danielcompton19:05:36

borkdude: do you inject the resource with component?

borkdude19:05:32

@danielcompton I define a function to create the resource. This function also takes some components that the resource can use.

borkdude19:05:34

But we have hooked up the yada listener in component, so we have to do rr/reset when we make any changes to resources (and routes for that matter).

danielcompton19:05:45

oh, reloaded.repl

borkdude10:05:51

Yes, sorry for my late response. I’m not good at tracking these threads in Slack.

borkdude10:05:58

It’s reloaded.repl indeed

runejuhl11:05:24

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

runejuhl11:05:24

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

stathissideris18:05:17

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

dominicm18:05:36

stathissideris: you haven't / prefixed hello

dominicm18:05:59

stathissideris: you can use grouping on / and "" to avoid the leading slash

dominicm18:05:16

The nil message is because you don't have a 404 handler

stathissideris18:05:15

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)

stathissideris18:05:37

oh it’s probably bidi

stathissideris18:05:16

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

borkdude18:05:36

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

borkdude18:05:00

@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#)))

borkdude18:05:08

to get a more realistic scenario

borkdude18:05:24

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

runejuhl18:05:13

@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")

runejuhl18:05:07

@borkdude that makes sense, thanks a lot!

stathissideris18:05:33

@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

stathissideris18:05:09

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

stathissideris18:05:34

I always get the old routes

stathissideris18:05:11

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

stathissideris18:05:37

maybe component is the only way to reload

dominicm19:05:57

I don't think you want to be dereffing there

malcolmsparks19:05:03

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

malcolmsparks19:05:35

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

runejuhl19:05:08

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

malcolmsparks19:05:26

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

malcolmsparks19:05:40

Need to announce later tonight

malcolmsparks19:05:21

@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!

stathissideris19:05:29

@malcolmsparks that’s very convenient, thanks!

malcolmsparks19:05:39

@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.

malcolmsparks19:05:21

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

malcolmsparks19:05:00

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

stathissideris19:05:36

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

malcolmsparks19:05:11

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

malcolmsparks19:05:44

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

stathissideris19:05:01

(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}))

stathissideris19:05:18

this is the code that plays well with reloading

stathissideris19:05:22

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”

stathissideris19:05:31

to get vertical lines in the graphs

nha23:05:56

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



Here is my vhost: (aleph/listener (vhosts-model [:* r]) {:port port :join? false}) Where r are my routes. How do I go about debugging that? nginx is basically doing a proxy_pass

dominicm06:05:47

nha: @U0ALP2929 I'm suspicious about the localhost/127.0.0.1 response, given your vhosts model. That isn't at all what I would expect to see. Could you confirm this is definitely your vhosts-model in use? The response you're seeing is definitely the one you have when the vhost isn't matched by bidi.vhosts

nha23:05:16

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