This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2016-06-29
Channels
- # admin-announcements (4)
- # arachne (19)
- # aws-lambda (3)
- # beginners (10)
- # boot (166)
- # capetown (32)
- # carry (160)
- # cider (5)
- # cljs-dev (5)
- # cljs-edn (19)
- # cljsrn (1)
- # clojure (100)
- # clojure-belgium (2)
- # clojure-dev (8)
- # clojure-greece (13)
- # clojure-new-zealand (12)
- # clojure-poland (1)
- # clojure-russia (93)
- # clojure-sanfrancisco (2)
- # clojure-spec (133)
- # clojure-uk (52)
- # clojurescript (129)
- # cursive (32)
- # datomic (13)
- # defnpodcast (5)
- # devcards (6)
- # dirac (4)
- # emacs (12)
- # euroclojure (5)
- # events (2)
- # hoplon (19)
- # immutant (45)
- # keechma (17)
- # lein-figwheel (27)
- # off-topic (9)
- # om (30)
- # onyx (17)
- # other-languages (3)
- # planck (2)
- # proton (11)
- # re-frame (7)
- # reagent (4)
- # ring (8)
- # sim-testing (2)
- # spacemacs (4)
- # testing (2)
- # untangled (162)
- # utah-clojurians (1)
- # yada (80)
@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?
@ilukinov: https://juxt.pro/yada/manual/intro.html is the maintained version. (index: https://juxt.pro/yada/manual/index.html)
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
@malcolmsparks: I have a question on your article https://juxt.pro/blog/posts/course-notes-2.html
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.
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?
@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?
@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
What is the client also accepts text/plain?
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
hi, just having exactly the same problem as @ilukinov, does anyone know what we're missing?
"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
1. first thing is to get the swagger UI up (even with the petstore) -- that should be http://localhost:3000
2. second thing is to get the swagger.json document - might be http://localhost:3000/api/swagger.json or http://localhost:3000/phonebook-api/swagger.json
Now you take the absolute URL of (2) and give it as a url query parameter to (1)
Eg..http://localhost:3000/swagger/?url=http://localhost:3000/phonebook-api/swagger.json
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,
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