Postman which I thought worked locally on my computer, is down

In case you aren’t familiar (and with apologies for my verbosity if you are): VSCode Remote can be best understood as a sort of hybrid of a local text editor and a remote web-based or X11 view of an editor for a remote session.

When you use a remote, the code is on the remote and all your editing functions (search, version control, terminal, extensions) happen in the remote via a worker process.

So in a remote session, everything is “local” to the remote. You may have no file “mount” of the thing at all on your host desktop machine. If you do a git commit, it’s running inside/on the remote. If you do a file search the files are searched on the remote, rather than downloading them over some network filesystem and searching locally.

The GP’s point is, I think: if you implemented Yaak as a VSCode extension, it could be made to function either in a local session or inside a remote (on a server accessed via SSH, a docker container, on the linux side of WSL etc.) and therefore have fast rather than slow access to the code, git repo etc.

I do essentially all my dev work (apart from compiling the odd mac app) inside remotes of various kinds to create reproducible environments, avoid cluttering the host, sandbox the tools, give me freedom to work from more than one machine etc., and I run into this sort of thing quite a bit.

There are at least two clients like this for VSCode —- Thunder Client and EchoAPI, and I believe both function in a remote session.

P.S. I loved Insomnia before the bad happened; it really helped with learning APIs. Thanks.

probably too much work for a solo dev

The REST Book extension was made by a VS Code dev and does a decent enough chunk of what is needed, at least for simple use cases.

Handy Dandy Notebook as well, but that requires some reformulation to get everything in terms of standard curl/node/python/etc commands. (whether that’s better or worse than a custom http dsl is a matter of some debate)

Also: httpBook - Rest Client

Wrote this late at night and didn’t explain what I meant by X11 view.

I was thinking back to running X sessions on remote machines, sending for example a text editor view back across the network to my desktop.

VSCode remote feels to my fiftysomething brain to be logically quite like that, only you are sending the display back from the remote worker using web techniques, and rather than to a display manager, you are sending it back into the shell of an editor, so it appears to be largely indistinguishable from a session running on your local machine.

Maybe I’m misunderstanding, but I think what you want already exists as VSCodes remote SSH tunnel port forwarding (not the one that makes it publicly accessible).

Startup a dev server on the remote machine and forward the port to localhost. It should now be accessible via http://localhost:[port] on your local machine in the browser or any application, as if it’s running locally.

I find it’s very useful for also for interacting with DBs/Redis. Just forward the port your DB communicates on and use whatever client on your local machine to interact with it.

As far as I know this works with any service that communicates via TCP

Yeah, it would help with using the tool to access a private-to-the-remote API.

Won't immediately help with giving that tool access to the file system or Git.

For a local VM, you can have file system mounts, fast enough for Git.

SSHFS could help in some genuinely distant remotes with access to the file system (though SSHFS in the context of multiple file writers is fraught with risk of file corruption; been there, bought that T-shirt).

With properly network-remote VMs, nothing helps that much with giving the tool access to performing Git operations on changes inside your remote: Git is slow over network file systems even when they are quite local.

This is the real power of the VS Code remote after all; everything happens there.