Introduced in process nrepl message processing

[deas]

This PR introduces the choice to directly call into nrepl - bypassing the network. At first, I considered removing the call over the network. I decided to keep it because we might wan't to act as a proxy and access a remote nrepl server. ;)

However, the option to use a (potentially different) nrepl-handler might even be useful. When playing around, I found that nrepl-refactor-middleware does not play nice with gorilla-middleware.

[JonyEpsilon]

Can I ask what the motivation for removing the socket connection is? Is there a use case where having the socket open on localhost is not acceptable? It would be helpful for me to understand the background to the PR (I'm guessing it's part of your 'embedding' drive, but don't yet see how it fits in to the big picture).

Regarding the middleware thing, I think there's no good solution to that with the way nREPL resolves middleware at the moment ... it wasn't really designed to accommodate more than one tool working with the same nREPL server. My goal at the minute is to stay compatible with cider-nrepl, as that covers most people's requirements.

[deas]

Using nrepl socket communication adds unnecessary overhead when nrepl runs in the address space of the webserver. Besides, it enlarges the attack surface and listening can fail when the port is already is use. Think about using it (embedded and "secure") in production. The PR does not remove socket communication. It adds choice to not use it. I still see use cases where one might need nrepl socket communication.

I fully understand your goal to stay compatible with cider-nrepl. The PR does not add any restrictions here. In fact, it adds flexibility. It allows you to use different middleware stacks depending on whether you call into nrepl via nrepl socket or in memory. I found nrepl-factor (which I consider fairly "popular") middleware conflicting with gorilla middleware when I used both on the socket service. Keeping nrepl-refactor mw on the socket service (for emacs) while moving gorilla mw to the in-memory call gets around this problem.

[deas]

Here comes another reason. ;)

In in memory-calls to nrepl plays nice with figwheel. Try my branch feature/cljs-parinfer (you should see parinfer working)

lein do cljsbuild once, figwheel

and go to http://localhost:3449/worksheet.html (assuming port 3449 is chosen).

It could be just:

lein figwheel

with incremental realtime browser code updates and other figwheel goodness once we have decided whether to stick with JavaScript or go with ClojureScript in the client.