Fork me on GitHub
#ring-swagger
<
2016-01-15
>
ikitommi14:01:33

what would you like to see in the Compojure-api roadmap? we will release 1.0.0 soon, can do breaking changes (for the better).

zamaterian14:01:32

It was fairly painless to upgrade to 0.24.1, at the moment I dont have any big pain problems. It would be nice to hear a bit about what you would like to implement simple_smile

juhoteperi14:01:29

That's the plan and already implemented changes

ikitommi14:01:49

Will do a good migration guide.

ikitommi14:01:00

Should buddy be integrated in? Many have asked that and there are codes for it, one can guard the routes with :roles #{:admin}.

ikitommi14:01:32

would make the lib much fatter, but I think most people use buddy anyway and would making the simplest possible secure api-app trivial.

zamaterian14:01:18

Its kind is it a lib or a framework question. I rather prefer to keep the dependencies small but add good support for addons. like buddy or friend. But then again security should be a first class citizen and not as an after though.

juhoteperi14:01:07

I don't think integration is required, we could provide a better documentation or maybe even a namespace for buddy but without transitive dependency on buddy

juhoteperi14:01:14

Complete integration, like automatically adding middlewares, would need MUCH special cases like storing sessions on different databases etc.

juhoteperi14:01:36

Also, with api it will be easier to wrap the compojure-api handler in middlewares than with defapi

juhoteperi14:01:19

Now one needs to create a var with defapi and wrap that with middlewares but with api only one var is needed

juhoteperi14:01:28

(defapi app' {...} (GET* ...))
(def app  (-> app' (wrap-session) (wrap-buddy)))
=>
(def app (-> (api {...} (GET ...)) (wrap-session) (wrap-buddy)))

zamaterian14:01:20

With the current impl. and our own macro atop of it. we fairly easy hits the method body is to large simple_smile

zamaterian14:01:46

And then the api brings in the compojure/ring-swagger middleware ?

juhoteperi14:01:03

Yeah. The same as defapi currently.

ikitommi14:01:09

api will be a function in 1.0.0, taking options map & handler. one can compose options.

ikitommi14:01:12

if there would be a :middlewares key in the options, one could just merge in the needed buddy-stuff. (api (merge buddy/api-options my-options) (context “/api” [] …))

ikitommi14:01:54

but then again, @juhoteperi ’s mw-threading is as simple.

ikitommi14:01:01

cool. with the new Routing-protocol, routing is separated from endpoints, which allows 3rd party endpoints publishing their api-docs easily. Will try to cook a Liberator-bridge later. Will ping you before starting on that.

zamaterian14:01:12

sounds great simple_smile if you want to see our impl. just say.

timgilbert21:01:06

One thing I'd like in compojure-api would be for my custom exception handler for schema errors to be able to access the request body, so I can log the incorrect input

timgilbert21:01:21

Not really a breaking change though. I'll file a ticket for it

timgilbert21:01:39

The other thing that would be nice would be if route-specific middleware had access to rebound vars, I use (context* "/:id") [] :path-params id ...) blocks quite a bit in my routes, and most of the things I'd want to use route-specific middleware for aren't very useful if they can't get the id out of the route

timgilbert21:01:04

...unless I manually parse it out of the response in the middleware, which I'm not anxious to do

juhoteperi21:01:12

@timgilbert exception handlers already can accesss req and check #198 for logging changes

timgilbert21:01:55

Thanks @juhoteperi, will take a look