Fork me on GitHub

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") 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/
so that's not the problem. I think it's more about the webjar. But I can't find it 😛.


Sorry, I meant. There's an s on the end.


Possibly just copy/paste mistake though.


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.


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.




Also, slack has a /shrug command. TIL


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


how does it resolve the path?


previously I was keeping my routes in an atom and once constructed dereference it and call bidi/path-for on it


but how should the yada ctx know about my bidi routes?


@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


yes, yada "1.1.37"


and for bidi I have no explicit dependency


oh, so I should wrap my routes in bidi.vhosts/vhosts-model ?


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


ha! it works. this is really cool 🙂


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


Hmm, Martian might interest you


that’s an appropriate name for these architecture-astronaut features


I only just got it


it’s exactly what i had in mind


but it uses swagger


personally i think swagger is too limited


i run into problems when i do s/either and things like that


Ah. Makes sense.


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


a government can supply both road maps and road signs


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 ?