path-prefix + middleware #148

[den1k]

Issue: https://github.com/nextjournal/clerk/issues/148

This adds functionality to embed clerk under a specific route in an existing app, e.g. with reitit style routes

(require '[nextjournal.clerk.webserver :as clerk.webserver])

["/admin"
 ["/clerk*"
  {:get (clerk.webserver/wrap-path-prefix
          clerk.webserver/app
          {:path-prefix "/admin/clerk/"})}]]

while prototyping this in a separate app I had to run bb dev and replace

https://github.com/den1k/clerk/blob/den1k/byoserver/src/nextjournal/clerk/view.clj#L36

with

(hiccup/include-js
  "http://localhost:7778/js/viewer.js")

[mk]

Gave this a spin and made a few changes. Currently the websocket connection isn't working yet and afaik this will require server specific work until Ring 2 gets widely adopted. I'm not really sure we actually want to support web sockets when running embedded for the time being, since we'd also need to think about authentication etc for this then.

Another thing that currently doesn't work is opening up more than one Clerk doc at the same time and lazy loading results for both. But maybe also something we can look at in a follow-up.

Thinking that a different handler where we actually pass in the file that should be displayed could also make sense. Would you currently still use clerk/show! in your setup?

[den1k]

Thanks for cleaning in up! I wasn't 100% confident it covered all edge cases.

Currently the websocket connection isn't working yet and afaik this will require server specific work until Ring 2 gets widely adopted.

Interesting, I remember it working for me. But my project happens to use the same server (httpkit).

I'm not really sure we actually want to support web sockets when running embedded for the time being, since we'd also need to think about authentication etc for this then.

Hmm, in my case I'm looking to build an admin interface using clerk which would have interactivity, e.g. creating users, running queries and I assume would therefore depend on websockets? Re: websocket auth, given my current auth middleware, I don't think any requests (whether websocket or http) would make it through to the clerk handler without first getting redirected through auth. So I doesn't seem that websocket would be an issue, since by the time the user would get through to the clerk route they would already be authenticated:

This can be done in a variety of ways, as WebSockets will pass through standard HTTP headers commonly used for authentication. This means you could use the same authentication mechanism you’re using for your web views on WebSocket connections as well. source

Thinking that a different handler where we actually pass in the file that should be displayed could also make sense. Would you currently still use clerk/show! in your setup?

I guess I'm implicitly using clerk/show! through the file watcher during dev but I don't use it otherwise. My goal is to be able to use this from my phone while in prod so I wouldn't have a remote REPL handy.

As for the showing specific files, my assumption was that the current handler covers all files under the prefix path but I might be wrong about that. Intuitively, if admin/clerk is the prefix path, notebooks is in src-paths and a notebook is my-app/notebooks/admin/clerk/db.clj then I'd expect going to my-app.com/admin/clerk/db to take me to the respective notebook.