Fork me on GitHub

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 If I launch Portal on the remote host, can I access it over another tunnel at ?


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?


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

An alternative to hosting the portal runtime in your production process, is to use the 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 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.


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


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


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 :)


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


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


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

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


No idea, what errors are y'all seeing?


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 -


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


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


What version of java are you using?


humm, good one, I think I changed recently


wilkerlucio@Wilkers-MacBook-Pro portal % java --version
openjdk 17.0.1 2021-10-19


Yeah, I think java 17 doesn't work


just rebuild here, the build went fine with JVM 11


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

๐Ÿ˜† 2
๐Ÿ™ 1

just tested, working fine

thanks3 1

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


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


but not sure if that's nescessary


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


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


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)


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


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


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

๐Ÿ‘ 1

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


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


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


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


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


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