Fork me on GitHub
#scittle
<
2024-04-11
>
chromalchemy23:04:55

In this setup https://github.com/babashka/scittle/tree/main/doc/nrepl , BB starts an nrepl server with sci.nrepl.browser-server. The editor (nrepl client) connects to it. The bb fn also starts a “websocket server”. The browser cljs connects to that with scittle.nrepl code. Conceptually then, what is the browser js/cljs context? Is that an nrepl “client” or “server”? If a browser page connects to a “browser-server”, is it a “client” of it’s own state? I’m confused. Also, why using sci.nrepl, why not bb.nrepl? Or does it use that under the hood?

Bob B03:04:31

I believe that: • bb/jvm is a 'server' that sort of acts a message conduit in this case - it starts an nrepl server that accepts nrepl messages (from the editor) and a websocket server that when a client (the browser) connects, it forwards the message along • the browser is the 'server' (in the context of the nrepl session) and a 'client' of the websocket connection to the bb/jvm 'conduit' • the editor is a client of the nrepl session I think this all exists because an HTML page being rendered doesn't have a way to run a server, so the conduit exists to accept an editor connection using the nrepl protocol. As for sci.nrepl vs bb.nrepl, 1) babashka is JVM-oriented, so scittle isn't going to deal with that at all, 2) the sci.nrepl dependency is used primarily to provide this browser-server multiple-server arrangement that is aimed pretty squarely at scittle, and isn't part of the babashka.nrepl library, and 3) because sci.nrepl's browser-server is more a message conduit than a message processor, it looks like it has quite different functionality from a 'normal' nrepl server - it's doing a lot less processing of the code in the messages, and a lot more sending requests to the websocket and responses back to the nrepl client.

👍 2
❤️ 2
🙏 2
chromalchemy17:04:23

Thank you. Still wrapping my head around all that. But it does demystify some things.

chromalchemy18:04:03

Outline of above (i think in outlines, preferably graphs 😅 to prevent 🤯) - components - bb/jvm - ‘server’ (conduit) - acts a message conduit - more a message conduit than a message processor - it starts - a nrepl server - that accepts nrepl messages (from the editor) - a websocket server - when a client (the browser) connects, - it forwards the message along - browser - ‘server’ - of nrepl session context - ‘client’ - of the websocket connection to the bb/jvm ‘conduit’ - editor - a client of the nrepl session - an HTML page being rendered - doesn’t have a way to run a server, - so browser cant accept and persist an editor connection - so the ‘server’ (conduit) exists to - accept and persist an editor connection - using the nrepl protocol. - sci.nrepl vs bb.nrepl, - babashka is JVM-oriented, - so scittle isn’t going to deal with that at all - the sci.nrepl dependency - is used primarily to provide - browser-server - supports multiple-server arrangement - aimed pretty squarely at scittle, - isn’t part of the babashka.nrepl library - more a message conduit than a message processor - it has different functionality from a ‘normal’ nrepl server - less processing of the code in the messages, - more sending requests to the websocket - and responses back to the nrepl client.