Fork me on GitHub

@tawus - are you giving it a path-info, e.g. if you resource is bound to /hello, you should try with a URI of /hello/foo so that /foo becomes the path-info


Those fixes to edge have been pushed. Edge now contains a working yada phonebook example. No swagger yet.


Ah that might be it. Thanks @malcolmsparks I will try it out.


Swagger added to phonebook. So now the phonebook example, with Swagger UI, swagger metadata and tags, etc. has been migrated to Edge so you can see how to put a non-trivial Swagger-assisted API together


Hello, trying to understand and use your yada lib, with no luck for now. Where can I find "Getting Started” guide?


@dominicm: thanks, will try that


Edge is good to download for yada.


Problem with edge for me: 1. It uses boot (121 lines of code in build.boot OMG), so I need to learn this tool to, although i just started to understand lein a little bit 2. Looking in to build.boot - 24 dependencies, only one is commented [weasel "0.7.0" :scope "test"] ;; Websocket Server -> my head exploding


I intend to create something similar, but om is not going to be the client (yet)


I just like to send edn over the wire to describe the query


Would it still be a good idea to use om/parser in that case? Is there any documentation on the format of the data that om is sending back and forth to a remote?


Yes. The Om Next query syntax is really a general 'pull' syntax. It's not too tightlt coupled to Om Next.


this is the thing, the db is datomic


but these are mobile apps doing the querying, and we're not using om next


oh, ok in there is a syntax for query expressions


nice article btw, you can't find that much info on the topic yet


why is om using transit instead of edn? performance?


What is the official way of adding support for my own data type to yada? There are the multimethods yada.body/render-map, render-seq and render-error for producing and yada.request-body/process-request-body for consuming but are they considered part of the public API?


By data type i mean mime type


when I needed to add support for transit I used those


they seemed to be public enough


@stijn: yeah, transit is way faster than edn. Thanks to @imre yada has good transit support.


Well then I have the problem that default error rendering ignores :produces on the resource and is hardcoded to only support those listed in yada.handler/error-representations so I am forced to add a wildcard :responses key to circumvent this and force content-negotiation to accept my mime type for errors


Wouldn’t be more logical that if a resources declares that it produces a mime type and that mime type is implemented for render-error that mime type is at least supported in content negotiation for errors?


I do remember render-error being a little strange when I worked on transit


but as I didn't really need it I wasn't paying too much attention


@griff. What if you only produce image/gif. What's the error then? A funny cat gif?


I know that may sound like a cool feature


Well if render-error is not implemented for image/gif i expect and empty response


What is the client also accepts text/plain?


Well yes the priority is a bit tricky


I haven't thought about errors too hard, there's scope to change things. I'd like the error stuff to improve


What happens if default error-representations was yada.handler/error-representations and :produces from the resource?


If a client sends Accept: image/gif, text/plain;q=0.1 then the error should be in text/plain - I don't see why not


When I last gave this area some thought I concluded that the only thing to do was to renegotiate the content type - that doesn't require any network hops, just taking the original Accept header and a new set of possible representations

Rachel Westmacott20:06:10

hi, just having exactly the same problem as @ilukinov, does anyone know what we're missing?

Rachel Westmacott20:06:47

"Cannot turn resource-model into resource"


@peterwestmacott: That is yada saying that the resource model (clojure map) is invalid according to the schema. There is a large defensive schema to ensure the resource is valid


@ilukinov: the manual is getting overhauled. The getting started chapter is better. The install chapter predates edge and is really targetted at seasoned Clojure users. Things are improving but slowly, yada is a big project


Hi @malcolmsparks Running the latest Edge, trying out the Swagger stuff. Not clear what I should browse to in order to see the API defined in the application. If I browse to http://localhost:3000/swagger/ I get the Swagger Petstore API!


@ijbriscoe: go to http://localhost:3000/ - don't you get a page with links you can click on?


the reason you get the Swagger Petstore API is that's the default if you don't give a url query parameter.


the links in the index.html page do givea query parameter to the swagger ui though


I do see the links. Thanks. Still figuring out what yada's Swagger implementation gives you, and what you need to do yourself... I'll look at that page to see how it's generated


@ilukinov: I sympathise with your frustration. Those 121 lines of boot are doing a lot - there's both dev and advanced cljs compilation, sass css compilation, a browser repl, stuart sierra workflow reloaded, an nrepl server, all the figwheel-like stuff adzerk gives you, automatic reloads...


Is it right that the swaggered function should provide a route that redirects to the UI, with the correct query parameter? I got very close to getting that working last night...


the point I'm making is that with Leiningen, all that black magic (and it really is magic), is hidden away from you - boot is just a timepiece with a translucent cover rather than an opaque one - it's taken us months to get everything to work (and it probably has some kinks left)


@ijbriscoe: it's confusing - there are 2 things you need to keep separate in your mind - there's the swagger.json generation, and the Swagger UI itself.


The swagger UI is built in to edge (and yada actually), it's convenient to do so


Yes - I think I've got the separation now - last night I was able to use swagger/swagger-spec to generate the json


The swagger.json generation piece is separate, it takes you bidi routes, containing your yada resources, does a tree walk over the whole thing and ends up with a swagger.json (you can get swagger.edn too actually)


the points of edge is to show you how it's all done.


I'm just struggling with the very last bit of integration, tying the json to the UI


I'll look at that index... I don't mind generating the link and doing a redirect if necessary


bear in mind that the swagger.json generation is (merely) a tree-walk, compare that with the hoops that compojure-api has to jump through to generate you the same document


but if it's provided anywhere in the API, I'd prefer to do that


1. first thing is to get the swagger UI up (even with the petstore) -- that should be http://localhost:3000


Agreed! There's so much to like in the yada + bidi combo


Now you take the absolute URL of (2) and give it as a url query parameter to (1)


OK - so I do understand it. Presumably I can compose that link using Bidi, if I tag the right resources?


yes, that's how edge does it - look in resources/templates/index.html - you'll see we use selmer {% %} tags - there's a special one that uses {% url ... %} and it uses bidi to generate the url to X, where X is tagged with edge.resources/X - there's not that much code to it


The point of edge is to show how it's all put together,


Great - I'll get back to edge and take a good look.


Without Edge it's been hard to explain to folks how to get the whole swagger thing working - and obviously the swagger UI has lots of its own js and images and css and stuff too


I've just pushed some more commits to Edge that tidy up the code and begin to add some comments - soon enough it will all be fully commented


But the build.boot thing is going to remain cryptic - it's really just to get the whole figwheel dev experience up and running - we're trying to show how yada, bidi and aero work together (and soon, skip too), rather than trying to show how boot works, so please just accept that the build.boot is crazy and your brain will explode if you try to understand how it works


(that's how I cope with it anyhow!)


@peterwestmacott: if you paste your resource-model and schema error I'll be able to explain what you've done wrong


what's skip? 🙂


That's my clojutre talk :)


If it's accepted


Anybody going?


@ijbriscoe: Also, having a single bidi/yada tree structure is a big deal - it's taken a long time - but it's not just to make swagger.json generation easier, the plan is much broader than that. Eventually they'll be lots of tools that can walk that tree and generate other formats and drive processes such as automating the creation of an API on Amazon's AWS API Gateway, so you might one day be able to develop your API in Clojure and 'deploy' it to a serverless infrastructure. There's also a chance that the same data will drive a clojurescript (nodejs) version of yada


It's certainly got a lot of potential; like many Clojure libs - I speak as a experienced developer, but Clojure novice - it takes a bit of effort to understand, but so far, well worth it