Fork me on GitHub
#luminus
<
2016-05-09
>
si1412:05:36

@yogthos: hi! I've read quite a lot of your posts and comments regarding current state of Clojure webdev (they are awesome, btw!), but I've never seen you commenting on a Pedestal (or I've somehow missed it). What do you think about it? In particular, I'm wondering about your thoughts on Ring middlewares VS interceptors. It seems like Pedestal's argument about middlewares being hostile to async processing is solid; therefore, middlewares are inherently flawed. Aleph also has this problem, but handwaves it away a bit with "this can be easily fixed by reimplementing the middleware using Manifold's let-flow operator". Do you consider adopting Pedestal (or at least its interceptors approach) for Luminus? If not, why?

yogthos13:05:54

I’ve never really used pedestal in production myself. However, I don’t actually see why async is attractive on the JVM. The reason it’s popular on Node is due to the fact that it's single threaded. JVM has a good threading model, and Immutant uses two separate thread pools for request listeners and request handlers.

yogthos13:05:32

I also think the async interceptor approach can make code more difficult to reason about than the Ring middleware stack

yogthos13:05:13

also worth noting that Immutant and HTTP Kit provide async extension for Ring handlers

yogthos13:05:01

I really don’t think that middleware is the right place to put code that incurs so much overhead that it needs to be run async

si1413:05:26

if I understand you correctly, you are talking about "async handling" as in "writing into socket asynchronously". However, there is also a notion of async meaning "abandon processing the request in the handler thread for now, freeing it up for other request". I agree about the former, however the latter is necessary for e.g. SSE.

si1413:05:41

ok, not strictly necessary, but desirable :0

yogthos13:05:00

right, and the second use case is already supported

si1413:05:13

yeah, but immutant just drops middlewares altogether in this case (again, if I understand it correctly)

si1413:05:20

I mean, the whole point of reply-processing middleware is to be there when stack gets unwound, but when we shift the processing somewhere, there is no stack anymore

yogthos13:05:45

yeah you do have to handle it differently there

yogthos13:05:21

although I find that you often have to anyways, for example if you have a websocket, regular middleware isn’t really applicable for it

si1413:05:27

another case I can think of where middlewares are still useful is streaming, e.g. large file streaming (where middleware can do things like encoding or metrics collection)

yogthos13:05:31

yeah that could benefit potentially

yogthos13:05:51

it might be worth bringing up on the immutant channel as well and see how others deal with it

yogthos13:05:25

I recall there was also a general async proposal for ring, but not sure if it’s still being worked on

yogthos13:05:11

but at the end of the day the current solution would be to simply wrap the async handlers in their own helper functions

si1413:05:06

yeah, I see your point, thank you. I didn't have an experience with Pedestal in production yet, too, but their reasoning around decoupling request and response parts of middleware and their tree-based routing make so much sense to me, at least on paper! In the same time I love how you are pushing Clojure web story forward, so I'm a bit frustrated that two great things (Luminus and Pedestal) don't come along nicely :)

yogthos13:05:07

I’m not really opposed to the idea of Pedestal, but I haven’t found Ring lacking in practice for most use cases, and it definitely is simpler to use

yogthos13:05:07

I know there’s a bit of work happening with Pedestal to improve usability, so perhaps it could be an option in the future

nnbosko19:05:07

Would I have to manually unmount components when I run a search, for example?