Fork me on GitHub
#nrepl
<
2019-04-08
>
lilactown14:04:25

I’m considering trying to connect to nREPL from a web app / chrome extension for a project. is there any prior art for something like this?

dominicm14:04:42

Drawbridge I think

lilactown14:04:44

I’m looking at drawbridge, which seems like it might be the way to go.

lilactown14:04:19

I’m a bit bummed that it requires a separate dep. the dream would be that I could just connect to any old nREPL server

shen14:04:21

Think the fundamental limit is that a web app will need to speak http or ws

shen14:04:02

and I don't think Java standard libraries provide either of those.

lilactown14:04:54

yeah. I wish there was some way for Chrome to connect to a regular ol’ socket 😭 pulling in an HTTP server for every project using nREPL seems potentially problematic

bozhidar14:04:49

> I’m a bit bummed that it requires a separate dep. the dream would be that I could just connect to any old nREPL server (edited)

bozhidar14:04:39

That’s hard to do as you need to bundle somehow an HTTP server with the REPL. Leiningen used to ship Drawbridge at some point, but I’m not sure if that’s still the case.

bozhidar14:04:43

In theory we could have a trivial self-contained http implementation bundled with nREPL, but there never was a lot of demand for this.

lilactown15:04:35

makes sense.

lilactown15:04:45

would you take a PR with something like that? I might be able to put something together, but I also understand if it’s just increasing surface area to support for something not many other people need

shen15:04:59

what's the usecase here, @lilactown?

lilactown15:04:26

I’m working on some devtooling a la REBL for the browser

lilactown15:04:04

I previously implemented my own shoddy protocol on top of websockets for Node.js / JVM, but I was thinking i might be able to simplify my life by just connecting directly to a REPL

dominicm15:04:12

I think the side loading work might be useful here?

dominicm15:04:30

I guess not actually, as you can't sideload a transport

lilactown15:04:11

specifically I’m now pivoting to a chrome extension that would connect to a remote session: CLJS in an inspected page, Node.js, and JVM. I previously implemented different “adapters” for each platform, but I know that most projects already have nREPL which would reduce dependencies users would have to install and potentially reduce the differences in implementation

shen15:04:51

this might be useful?

lilactown15:04:21

I looked at that as well. it’s still another transport, right? and it didn’t look like it had been updated in awhile, so I wasn’t sure if it supported the latest nREPL

shen15:04:44

I imagine step one is getting this all to work with drawbridge/your own http transport

shen15:04:02

and then check if it's worth trying to merge the functionality into nREPL

shen15:04:12

I've seen some roll-your-own HTTP implementations, and if you are super narrow about the usecase, it can be manageable. But all depends on what it looks like

lilactown15:04:56

yeah. I’m afraid that it will bloom into “now nREPL has a fully-fledged HTTP server impl” lol

bozhidar15:04:00

> I looked at that as well. it’s still another transport, right? and it didn’t look like it had been updated in awhile, so I wasn’t sure if it supported the latest nREPL

bozhidar15:04:45

Not really. It’s just a ClojureScript REPL based on piggieback.

shen15:04:08

isn't it a way to speak to piggieback via a websocket?

shen15:04:53

think it's part of boot's counterpart to lein-figwheel

bozhidar15:04:02

> yeah. I’m afraid that it will bloom into “now nREPL has a fully-fledged HTTP server impl” lol

bozhidar15:04:10

That’s always a possible outcome. 😄

bozhidar15:04:07

> I guess not actually, as you can’t sideload a transport

bozhidar15:04:21

@dominicm You won’t need to sideload it, thouhg. You could inject it in the initial payload you’d use to convert a socket repl to nREPL. Once we get there that is. @cgrand already has some branch where the injection works, so I guess that’d be just an extension of this idea.

cgrand16:04:11

hmm no the injection is not done yet (been busy)

bozhidar16:04:54

yeah, I know. Just remember that demo you showed me way back in December and that we spoke that the injection could be a good way to provide custom transports seamlessly.

dominicm16:04:35

@bozhidar I don't think that browsers let you make arbitrary socket calls.

bozhidar16:04:25

Good point. That approach would work for conventional clients, but not for @lilactown’s use case.

lilactown16:04:13

I kind of want just a dumb endpoint that I could dump some code into to “inject” stuff, like a heavier HTTP transport if needed

dominicm17:04:01

An interesting idea would be to have the default transport allow sideloading via a very dumb detection of http request

dominicm17:04:20

Not sure how much parsing would be needed for the cases we want to support.