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 ?

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.

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.

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.

IJ needs an updated plugin to work with 2021.3.

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)