This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2024-04-11
Channels
- # announcements (2)
- # babashka (31)
- # beginners (31)
- # calva (30)
- # cider (23)
- # clerk (1)
- # clojure (46)
- # clojure-austin (5)
- # clojure-brasil (1)
- # clojure-europe (47)
- # clojure-nl (1)
- # clojure-norway (72)
- # clojure-uk (2)
- # clojurescript (39)
- # conjure (1)
- # cursive (16)
- # data-science (1)
- # datomic (35)
- # dev-tooling (4)
- # events (5)
- # introduce-yourself (2)
- # jobs-discuss (5)
- # missionary (3)
- # polylith (11)
- # releases (4)
- # scittle (4)
- # shadow-cljs (18)
- # spacemacs (16)
- # specter (2)
- # squint (27)
- # xtdb (6)
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?
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.
Thank you. Still wrapping my head around all that. But it does demystify some things.
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.