This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-10-04
Channels
- # aleph (3)
- # beginners (37)
- # boot (45)
- # carry (1)
- # cljsrn (15)
- # clojure (78)
- # clojure-austin (2)
- # clojure-brasil (10)
- # clojure-czech (3)
- # clojure-dev (12)
- # clojure-dusseldorf (31)
- # clojure-hamburg (2)
- # clojure-italy (4)
- # clojure-poland (2)
- # clojure-russia (37)
- # clojure-spec (25)
- # clojure-uk (30)
- # clojurescript (160)
- # cursive (40)
- # data-science (1)
- # datomic (31)
- # emacs (7)
- # figwheel (4)
- # hoplon (73)
- # leiningen (1)
- # liberator (5)
- # luminus (7)
- # numerical-computing (1)
- # off-topic (31)
- # om (89)
- # onyx (66)
- # proton (5)
- # protorepl (1)
- # re-frame (18)
- # reagent (2)
- # ring (2)
- # spacemacs (1)
- # untangled (93)
- # vim (19)
- # yada (67)
my (yada) api roughly looks like this:
["/"
{"v1" (swaggered ...
["/" {...}
{:info {...}
:tags {...}
:basePath "/v1"})
"swagger/with-jwt.html (yada (io/resources "swagger/with-jwt.html"))
"swagger (yada (new-webjar-resource "swagger-ui"))
"status" (yada {:status ok :version (read-version)})}]))
This works fine when run locally. However, when I put on a remote server, /v1
works, and /status
as well, but /swagger
or /swagger/with-jwt.html
gives this:
java.lang.IllegalArgumentException: cannot treat nil as HTTP response for request to ''
at aleph.http.server$invalid_value_response.invokeStatic(server.clj:133)
at aleph.http.server$invalid_value_response.invoke(server.clj:130)
at aleph.http.server$handle_request$fn__16419$fn__16420.invoke(server.clj:186)
...
I'm missing something here (again). It seems that the webjar resource is somehow not found?@kurt-yagram Does it happen in an uberjar locally? Might help figure out the difference between remote and local. Also, you could try print the webjar resource more directly on startup, figure out if it's bidi or -
> (io/resources "swagger/with-jwt.html")
http://clojuredocs.org/clojure.java.io/resource I think this is wrong. Probably not nil though.
yeah, that's what I don't understand. It works locally... weird.
I do have the html file:
$ ls resources/swagger/
mumtobe.html
so that's not the problem. I think it's more about the webjar. But I can't find it 😛.Well worth trying to print out the resource when the application starts, see if it's yada acting strange on the server, or your application in general.
allright.
hmmm, it's nginx something... when I run localhost:3000/swagger/with-jwt.html
remotely, it does work fine.
When I try to access via browser (on curl on my local pc), i.e. with nginx as reverse proxy, it returns the nil
-thing - by the way, is there a way to show a nicer message when the requested resource is nil?.
I wonder if yada is getting hit with a slightly different url or something. No idea what it could be really.
I'm not sure how to do it exactly. I think the trick is walking over your resources. But, unsure.
well, it's probably nginx config. will have to check that
dunno what was wrong. 2 nginx restarts, and a few browser refreshes and it all works fine.
I'm getting clojure.lang.ExceptionInfo: Context does not contain a :uri-info entry
when calling path-for on a ctx
I've searched edge and yada repos for uri-info, but I don't see where this gets set or what I should do to have it set
previously I was keeping my routes in an atom and once constructed dereference it and call bidi/path-for on it
@stijn Hi there - what's your current bidi/yada version?
Here's what's going on - bidi's bidi.vhosts/find-handler
is the function involved. Bidi 2.0.12 switched from uri-for
to uri-info
. It was just too confusing that uri-for returned a map, so I've renamed to uri-info
The latest yada (1.1.37) picks up this new version of bidi.
So if you've upgraded yada, make sure you're not overriding the version of bidi
@stijn - yes, if you're using yada's uri-for, because forming urls to routes, yada needs to be able generate absolute uris in many cases (Location headers), so the idea is that you use bidi's vhosts support if you use yada, and yada/server
does this
it's an area that's been stabilizing these last few weeks, so sorry for the breakage
I assume that people who upgrade to later versions are happy with some upgrade pain, but I've found that people are upgrading very quickly these days (partially thanks to things like lein-ancient).
That's created more of an onus on library developers to maintain strict compatibility between versions, I try to do that in general but sometimes it's nice to hide behind a library version
@malcolmsparks no worries about breakages, i'm finally upgrading from pre-1.1, so this is like a minor update 😄
I understand the use case of Location headers e.a. but our backend currently doesn't really care how requests come in. We have 2 domains routing to the same REST API.
does yada determine the uri-info on the incoming request domain, or do I have to list up all the vhosts as a 'synonymous vhost' in bidi?
you need to list all the vhosts (currently)
happy to discuss future functionality
ok, does it make sense to detect uri from incoming requests? because we are currently not using any vhosts and everything that gets routed to the API (load balancer traffic, but also inter-machine traffic that's routed differently) will get a response served.
It would probably make more sense to backport the uri-for change to the main part of bidi, and cut down the bidi.vhosts namespace a little.
btw, lately i’m thoroughly considering making a complete ‘bidirectional’ interface on top of yada, but i’m not sure whether that’s a good idea
we have quite a few yada microservices over here, and they all have their ‘interface’ in a thousand http/get
statements
i would love to be able to use uri-for
to generate urls between loosely connected services
https://juxt.pro/blog/posts/martian.html it's for exploring other's planets
@lmergen i'm a little hesitant to recommend a strategy of centralizing routes, although I'm interested in Martian (obviously) and what Oliy is doing with it
My default position is that URIs should be discoverable from the services that provide them. So responses (especially those in JSON) should use bidi to construct links to other resources provided on the same server. That's why bidi was developed - to make this accurate and less error-prone
However, centralising all URIs seems brittle to me. I think they feel a little too much like WSDL, CORBA Naming, etc.
When you change URIs (and you inevitably do), you want your clients to work regardless. However, if you are in control of all clients and servers (as Oliy and his team are) then it seems perfectly fine to use a common model.
But I think people should understand first the REST approach and how it can solve this problem (by hypermedia), before resorting to alternatives that are (even) less tried and tested
To use an analogy, if you drive to a destination, should you take a (potentially out-of-date) road map, or follow road signs? What happens if there's a diversion or road block?
To collapse the analogy, of course, you'd take a sat nav 🙂
I think the rule of thumb here is that if you're developing services to support external users (public, or in other departments in your org), then you should think about longevity and how those users can use hypermedia to navigate change
If you're in control of everything, then it's fine to use a central model. I think HTTP presumes the former but works perfectly well for the latter.
@malcolmsparks depends on the satnav. Satnav's road map might be outdated. It would be best if the satnav read the road signs around me, and figured out the new road map as I went ... 😉
i actually don’t think these approaches are as mutually exclusive. you can perfectly do both.
in the end, you want to reduce the amount of problems you have in production; increasing the understanding of the http client about the service it is talking to will only help this cause. also, doing everything purely in REST mostly works in theory, but not in practice (for example, implementing pagination is something that every dev shops seems to invent its own solution to) what are the real downsides, actually, of projects like Martian, other than the philosophy ?