Thank you. As soon as Postman asked for a login I uninstalled it and have been curling from text files ever since. My younger coworkers won't drop Postman though. Maybe this will help them switch.
Especially once a VC gets into the fold.
1. Open source everything, including the parts of the code that are currently premium
2. Switch to a copyleft license like the GPL
3. Start accepting substantial contributions from the community without a CLA
Then they'd be legally unable to do that kind of rug pull.
Happy to see Bruno at the top of HN
We will never take VC funding. We received around 10 inbound reach outs from VCs till date and have denied funding from all of them.
We will remain independent and I have written about it in detail here https://www.usebruno.com/blog/bootstrapping
They haven't.
Like, that's kinda the whole point of offline-first, local-only tools, you can 100% use them in a an environment you control and take responsibility for. Once you take control of customer's data, there's a whole litany of due diligence that must considered, and often at considerable cost.
Your link makes sense, and I believe you. Have struggled with similar issues. But who knows what the future will bring? Google once said "don't be evil"; Oracle bought Sun. Is there any way you can guarantee your future actions? Contracts, articles of association/company constitution? Maybe setup a trust or charity? I don't think there is.
Though Insomnia doesn't work with streaming responses at all, which is a bit of a non-starter in the age of AI. Anyone know a good streaming HTTP UI?
https://gist.github.com/CMCDragonkai/6bfade6431e9ffb7fe88
If not, is there an example of "streaming HTTP" you could provide that illustrates the limitation
Of all the http-client applications I tested (Curl, Postman, Insomnia, Bruno), somewhat hilariously Curl has the best support. It will output all 'Transfer-Encoding: chunked' with line-by-line buffering, whereas Postman only supports responses precisely following the `Content-Type: text/event-stream` format (strictly less powerful than curl, as this format requires newlines in between events, and a bunch of overhead on top of that). The others buffer the entire response before displaying anything.
The `Content-Type: text/event-stream` format is fine enough, but I personally prefer to just plainly chunk the responses and let the client choose whether to buffer them into memory and operate on the entire value at once, or interpret them live as the chunks come in. With tools like gjp-4-gpt (Gradual JSON Parser 4 GPT's) you can even interpret partial JSON objects live as they come in and display complex/nested data structures in a generative manner.
https://cr.yp.to/proto/netstrings.txt
Personally I use a lame but effective simple 85.9 KiB static binary filter, a small C program, that removes the chunk sizes so the response is ready for use by other programs, e.g., in a pipe. Buffer is set at 8 KiB.
Is there a way to experiment with one of these streaming JSON GPT APIs non-interactively by just sending an HTTP request, without need for a third party program, an account, use of a Javascript engine, etc.
I don't know a public API that returns JSON slowly, but you could simulate it by just taking a JSON string, splitting it into 3-5 char chunks, and sending each of those in a `Transfer-Encoding: Chunked` response at ~100ms intervals.
Actually, now that I look at the underlying mechanism behind `Transfer-Encoding: Chunked`, it looks like it's already basically the same as the netstrings. What I'm referring to is the (variable length) contents of the netstring/chunk being sequential slices of a JSON object.
Only for the flexibility to use more programs. Otherwise every program I use to process HTTP responses needs to be able to accomodate chunked transfer encoding. Plus only a minority of sites send chunked responses. Instead, have one program that does one thing: remove chunked transfer encoding.
IIUC, what you want is uniform chunk sizes where you know the size before you send the request.
GPTs sound annoying if they are so slow that they only output a few characters every ~100ms..
> IIUC, what you want is uniform chunk sizes where you know the size before you send the request.
I don't think so... I don't really want anything! Just a GUI that displays existing HTTP chunked responses as they come.
> GPTs sound annoying if they are so slow that they only output a few characters every ~100ms..
That's perhaps an exaggeration, but in general the speed and "smartness" of the model are inversely correlated.
Best of luck. Hope you can find the right program for viewing HTTP.
You'll never guess who makes it.
Depending on which project I'm working on (and customer), I'll be using different tools to run em.
But to show you an easy example to follow, you could check out this jetbrains cli tool https://blog.jetbrains.com/idea/2022/12/http-client-cli-run-...
[1]: https://hurl.dev
How do you know it’s not a great experience?
(Apparently it has a GUI version as well, but I'm not interested in trying it.)
http localhost:1234/end/point Authorization:$bearertoken arg1=hello arg2:='{"a":42}'
http .. "`Authorization`" ..
But attitude like yours has shifted people and money away from developer tools. Instead of all the possible tools we could have from many developers, we are now totally dependent on big tech to sponsor it, like VSCode etc. And over time it would move in direction that will promote another service from the same company like copilot and vscode.
Someone needs to invent a hat that developers have to wear: when the developer starts to write signup, login or authentication code, a hand pokes out of the hat and slaps him.
If I buy a circular saw, I don’t want a relationship with Makita. I don’t want to have to log in to use it. I don’t want it telling Makita how many boards I cut and how well the saw is working. No offense, but I’m just not that into you, Manufacturer.
(The second and third 80%'s still need human intervention).
Takes slightly longer the first time than curl or Postman. But much more powerful in terms of using in scripts for operations tasks.
Not to mention, that bru syntax looks really nice.
As it is the things I test start up faster than postman who is … I don’t know what it was doing when I quit on it.