This is exactly why I made Yaak [1]. It's fully offline, no telemetry, open source, and can even sync with Git.
replies(24):
I haven't used postman or insomnia in a while since they went to the cloud, so I could just be missing it, but that's also a non-starter for me.
Sincere question, been studying lots of OSS commercial licensing and always wonder what works in which context
how would someone use this in a project that operates within VS Code Remote where the source sits on a remote server and isn't physically on the file system.
Yes, it's a good-faith license. The license doesn't even apply to the OSS version (only prebuilt binaries).
The bet is that super fans will pay for it in the early days and, as it gets adopted by larger companies, they will pay in order to comply with the legalities of commercial use. So far, it's working! The largest company so far is 34 seats, with a couple more in the pipe!
I'm not quite sure why Yaak wouldn't work in this case. It it because your running server wouldn't be accessible to Yaak, running on your system?
It makes good sense because companies actually have an absurd amount of liability to you if they violate your agreement.
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.
You can be an Oracle and audit your customers and develop that adversarial relationship. The idea is that that sort of thing makes you rot in the long run.
And the solo dev has a better product already and might actually win haha.
Underdog story.
Rooting for you!
These api clients are rocket science, the barrier for entry is very low.
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)
One idea: since you are doing good-faith licenses anyway, maybe you could add in the possibility to pay for some kind of one-time license? I don't particularly need or want updates from my API tool, I just want it to work and not break. I would be fine with paying a one time commercial license that gives non expiring right to use a particular version.
Edit: oh my, you also made Insomnia, that I used when Postman was on the enshittification path...
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.
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
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.
Thanks!
They have a lot of inerita, but that's it. If you're in Greenfield development, there is a close to 0% chance you will choose Oracle as your RDBMS.
Um, oops.
But that's A) me personally and B) me in Cloud/Startup type companies, so of course we don't got with Oracle.
But like you mentioned, inertia. So my previous gigs that were large multi-national of course were all Oracle. And they were all huge and had zero reason to not just buy the Oracle tax. Which is why Oracle is going strong.
Despite all the rage, Oracle can still survive quite some time on running boring things like I don't know, many large banks and other boring old businesses. Which of those is really gonna go "AWS Aurora MySQL" when the have had an in-house "Oracle Exadata" run their entire business operation "just fine" for longer than those Cloud providers have even be around?
I didn't know you created Yaak!
I just downloaded Yaak and it's been awesome, thank you!
I downloaded this through AUR on Arch and one bit of feedback is that I wish you'd make the sig verification a whole bunch easier, thanks!