Fork me on GitHub
#portal
<
2021-11-30
>
orestis08:11:38

I'm always repl-ing into a remote production server for support, troubleshooting etc. I would love to have better visualisations, but I am confused on if Portal can be accessed remotely? E.g. I REPL-connect via a tunnel to foo.repl.dev:52348. If I launch Portal on the remote host, can I access it over another tunnel at http://foo.repl.dev:8080 ?

orestis08:11:29

I see there's a remote api that would mean I would run Portal on my local machine, then from the remote machine I would submit values back to my local machine, but that probably means I need to configure a reverse tunnel so that the production server has access to my local machine?

seancorfield17:11:22

You'd need Portal as a production dependency in your deployed apps (which we do not do at work). You would need to have the Portal server port opened, at least in the DMZ/via a tunnel, so you could connect to it from your local machine. But with those in place, it should work.

๐Ÿ‘ 1
djblue17:11:13

An alternative to hosting the portal runtime in your production process, is to use the https://github.com/djblue/portal#remote-api which would allow you to send taps from the remote process to your local instance of portal. The only code you would need running in the production app is something like https://github.com/djblue/portal/blob/master/src/portal/client/jvm.clj. That namespace isn't very standalone currently, but it could be stripped down based on what you wanted to run in production. Essentially posting edn to a portal endpoint is sufficient.

djblue17:11:35

However, this would only work for inspecting values that could be serialized as edn

seancorfield18:11:32

And the "production process" would need to know -- and be able to reach -- the port/address of your local instance...? How would that work?

orestis18:11:39

I'm not too worried about that (serializing values to EDN) as it's already a requirement for text editor-based inspectorsโ€ฆ vim can only show text anyway :)

orestis18:11:16

But what Sean says is the sticking point, how to get the reverse tunnel going.

djblue18:11:35

Yup, my assumption is you could use something like a reverse ssh tunnel to expose your local Portal port on the production server.

djblue19:11:28

Something like:

ssh -N <remote-host> -R <remote-port>:localhost:<local-port> -C

R.A. Porter18:11:48

IJ needs an updated plugin to work with 2021.3.

๐Ÿ˜ญ 3
wilkerlucio19:11:18

I see this too, do you have any idea what kind of changes it needs @djblue?

djblue19:11:17

No idea, what errors are y'all seeing?

wilkerlucio19:11:08

I haven't upgraded yet because I dont wanna lose portal ๐Ÿ˜…

โค๏ธ 2
R.A. Porter19:11:10

That's probably it, though I know that Cursive needed a quick update for some breaking change in 2021.3 final - https://twitter.com/CursiveIDE/status/1465519556999331841

djblue19:11:12

I hope I don't always have to do a new release for every new version of intellij. This was part of the scaffolding so not sure if a version range could be specified

R.A. Porter19:11:06

There might be a way to give a range...either in maven notation or JS-style

wilkerlucio19:11:10

I tried to bump the IntelliJ version and build, but that fails with General error during conversion: Unsupported class file major version 61

djblue19:11:16

What version of java are you using?

wilkerlucio19:11:15

humm, good one, I think I changed recently

wilkerlucio19:11:16

[email protected] portal % java --version
openjdk 17.0.1 2021-10-19

djblue19:11:05

Yeah, I think java 17 doesn't work

wilkerlucio19:11:08

just rebuild here, the build went fine with JVM 11

wilkerlucio19:11:20

once things index I can try to run the thing ๐Ÿ˜›

๐Ÿ˜† 2
๐Ÿ™ 1
wilkerlucio19:11:24

just tested, working fine

thanks3 1
wilkerlucio19:11:38

all I did was change the gradle version to version = '2021.3'

wilkerlucio19:11:03

I also bumped id 'org.jetbrains.intellij' version '1.3.0'

wilkerlucio19:11:10

but not sure if that's nescessary

djblue20:11:15

I'll see if I can find a way to specify a range or something

wilkerlucio19:11:18

I see this too, do you have any idea what kind of changes it needs @djblue?

xceno20:11:10

Not sure if I'm doing something wrong, or if it's just the nature of things: I start portal via (portal.api/open) in intellij in the process of my server. I hook up a tap target in my cljs frontend like so: (add-tap (partial p/submit {:port 5678})) Now, when I tap some "huge" maps, my UI thread gets stuck for ~2seconds. So that means tap> is waiting for the fetch promise inside portal.client.common/->submit to resolve right? (Thinking about it, maybe that's more of a general clojure question)

djblue21:11:07

Might want to switch from the default edn format to transit :thinking_face:

djblue21:11:45

(add-tap (partial p/submit {:port 5678 :encoding :transit}))

xceno21:11:31

good hint, thanks! Transit is still taking a bit of time, but not as much, so it's good enough for now ๐Ÿ™‚

๐Ÿ‘ 1
djblue21:11:41

Just so I can keep track of it, how large is the post body request?

xceno22:11:11

Hm, around 50kb as string. It's a bit weird, I tried to tap such a map right now, and it wasn't sent at all. Then I put the entire map through str and it got sent again. Could be something weird going on on my part though

djblue22:11:15

The main constraint around the remote-api is that your value is serializable

xceno10:12:26

So after a good nights sleep I realized what's going on. Like you said, my values need to be serializable of course and before I switched the protocol to transit, everything got stringified. The stuff I tapped has some atoms, js objects and deep recursive structures in it, so yeah... picard-facepalm

djblue16:12:55

If you have objects, consider using portal.web ๐Ÿ‘Œ

djblue16:12:27

In the future, I plan on supporting non-serializable objects in a remote context