Support for async

[ansman]

It would be nice if liberator would support async endpoints.

One way to do it would be to use core.async. If a handler/action/decision returns a core.async channel the caller should also return a channel.

If there is interest for it I'd be happy to take a shot at an implementation.

[ordnungswidrig]

How would the integration work? I did not find anything about the ring spec supporing core.async or any other mechanism for server push.

[ansman]

Actually, I'm using http-kit which supports async requests.

[jeluard]

Do you have some specific idea in mind?

http-kit async support is mostly useful for websockets and long-polling/SSE but that doesn't really fit liberator REST-like model.
What would that add compared to just handling those outside liberator?

[ansman]

The thing is that I will be talking to Facebook in my app which takes quite a long time so I don't want to lock a thread while doing this.
I will be using WS but most of my app will be async REST endpoints.

If I don't use liberator I will have to do content negotiation and things like that on my own, something I would like to avoid.

I would say that async is a crucial part of any high performance web server.

[jeluard]

Ok I was discussing something different then. Sounds similar to pedestal async processing concept. Also see #56.

[ansman]

Yeah, it sounds similar.

Not sure what pros or cons the pedestal solution has but it seems a bit messy to me.

I guess the pro with core.async is the nice syntax but a downside is it isn't supported by ring.

[jeluard]

Looks messy to me too. Relying on core.async seems cleaner and easy to plug with http-kit (if it does not move to core.async itself?).
Look forward to see some more details on this :)

[ansman]

I'll get some code together and you can see what you think.

[ordnungswidrig]

Having blocking requests just because you have a long backend request seems unnecessary to me. I suggest to response with 202 Accepted or 303 See other, where either response would redirect to a resource representing the actual result of the long running request.

[ordnungswidrig]

In case of a streaming response, e.g. web chat, then some way of providing an async response could be fine. However, this is something that must be supported by ring the adapter. Ring allows the handler to return an InputStream; I don't know if this is a viable option to stream a response to the client.

[ordnungswidrig]

FYI there is http://ring-clojure.github.io/ring/ring.util.io.html#var-piped-input-stream which you can return from a handler.

[jconti]

With reference to returning a 202 or 303 for a long running task, long polling is useful then in the case where a client wants to then block on the resource that represents the long running task. Automated clients can decide if they want to follow to the new link and long poll (like a browser), or just poll the endpoint with a timeout asynchronously. I think this is useful, I've been using something similar for pub/sub over HTTP that has worked out quite nicely. Such a solution is easily debugged with a browser, and flexible for clients (they can choose async or sync).

[xfeep]

If we let liberator run on nginx-clojure which supports ring handler and after we enable coroutine based socket from nginx-clojure , the socket blocking won't lock a thread anymore. Our old code which based on synchronous blocking Java Socket API need not be changed and the executions of them will become non-blocking.

[cch1]

After much dwell time, ring-clojure has released version 1.6 which supports async processing. The model that it supports is mechanically convertible to aleph and http-kit. It would seem that the ring model (an arity-three handler function) would work nicely with liberator's content negotiation and validation functionality.

[ordnungswidrig]

Core.async is independent of support of Ring's new async response processing. I think the latter would be a good feature and deserves discussion. Let's close this issue and have a separate one for Ring's async support.

[ordnungswidrig]

See #280.

[cch1]

Sounds like a good idea. I did not realize this issue was just for core.async, but it makes sense to separate the issues as support for one does not imply support for the other.