I first want to say thanks for a great boot task, this is very helpful.
My current api setup does not make it easy for client-side developers. In order to get around CORS and other resource-allowed security issues, I have to proxy things around. Requests to /api are proxied to the actual development api, while all static-file requests are served from a local fileserver.
While trying to get boot-http to play this proxying role, I notice the TTFB slows dramatically (500-800ms to 2500ms). I can't see anything obvious in the source that would cause this slowdown, except for the fact that I'm using -H 'my.handler, where my-handler (and its dependencies) could be choking the pipeline:
(defroutes routes
(route/resources "/" {:root "target"})
(route/files "/" {:root "target"})
(route/not-found "Page not found")
(OPTIONS "/v1" []
{:status 200
:headers {"access-control-allow-origin" "*"
"access-control-allow-credentials" true
"access-control-allow-headers" "allow, content-type, cache-control, authorization, location, if-none-match"
"access-control-allow-methods" "GET, PUT, POST, DELETE, OPTIONS, PATCH"
"access-control-expose-headers" "allow, content-type, cache-control, authorization, location, etag"}}))
(def app
(-> routes
(wrap-proxy "/v1" "my.development.api/v1")))
This all looks like pretty standard stuff that is widely used, and I can't imagine that's what's causing the slowdown. After some more exploration I noticed that the boot task itself when declaring :reload true seems to cause the dramatic TTFB reduction.
(serve :dir "target" :handler 'proxy.core/app :reload true) <-- 2500+ ms
(serve :dir "target" :handler 'proxy.core/app) <-- 500-700ms
I guess I have two questions- 1) any idea why this is so much slower? 2) the ring-reload here is just reloading my proxy.core/app.cljs routes files if that changes, correct? If that's the case I can happily turn it off since this is just a simple dev-only proxy server.
I first want to say thanks for a great boot task, this is very helpful.
My current api setup does not make it easy for client-side developers. In order to get around
CORSand otherresource-allowedsecurity issues, I have to proxy things around. Requests to/apiare proxied to the actualdevelopmentapi, while all static-file requests are served from a local fileserver.While trying to get boot-http to play this proxying role, I notice the TTFB slows dramatically (500-800ms to 2500ms). I can't see anything obvious in the source that would cause this slowdown, except for the fact that I'm using
-H 'my.handler, where my-handler (and its dependencies) could be choking the pipeline:This all looks like pretty standard stuff that is widely used, and I can't imagine that's what's causing the slowdown. After some more exploration I noticed that the boot task itself when declaring
:reload trueseems to cause the dramatic TTFB reduction.(serve :dir "target" :handler 'proxy.core/app :reload true)<-- 2500+ ms(serve :dir "target" :handler 'proxy.core/app)<-- 500-700msI guess I have two questions- 1) any idea why this is so much slower? 2) the ring-reload here is just reloading my
proxy.core/app.cljsroutes files if that changes, correct? If that's the case I can happily turn it off since this is just a simple dev-only proxy server.