Earlier quoted context omitted.
If you use IntelliJ based products, the builtin HTTP Client is awesome. https://www.jetbrains.com/help/idea/http-client-in-product-c...
If you use computers, Curl is awesome. https://curl.se/
Bruno: Fast and Git-friendly open-source API client (Postman alternative)
271–280 of 444 posts
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#272Hey everyone, this is Anoop - creator of Bruno. Happy to see Bruno at the top of HN! I will try to address some common questions in this comment. > Well based on historical experience with Postman and Insomnia most probably Bruno will go the same way once they get enough users hooked in. Especially once a VC gets into the fold. We will never take VC funding. We received around 10 inbound reach outs from VCs till date…
Did you design the logo? I saw it and immediately wanted to buy a license! Great product!
The real Bruno looks like the logo too :) https://www.usebruno.com/about
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#273Earlier quoted context omitted.
It's not very fun to run the auth call, then copy and paste the access token to the next call, and have to update all of your curl cmds all the time... Even if you use env variables, that's a horrible way to use env variables.
You’re making the case for automation, which happens to be something the shell excels at. Use unexported shell variables or command substitution (e.g., “$(pbpaste)”). Directly use the result of the auth call without going through the clipboard if possible. Create a shell script if shell history isn’t enough. Use interactive notebooks if you need something more advanced. The possibilities are infinite.
Or perhaps write a script that has some kind of GUI.
Or maybe make the gui run the URL
You're right the possibilities are endless. And this Bruno and postman or permutations of that endlessness.
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#274Hey everyone, this is Anoop - creator of Bruno. Happy to see Bruno at the top of HN! I will try to address some common questions in this comment. > Well based on historical experience with Postman and Insomnia most probably Bruno will go the same way once they get enough users hooked in. Especially once a VC gets into the fold. We will never take VC funding. We received around 10 inbound reach outs from VCs till date…
I'm strongly considering buying it because it's not a subscription, and is open source. As a general rule, I don't buy proprietary software anymore after having been burned in the past. I have no issues with open source software that has proprietary features as a way to make the project sustainable, if they are source available for paying customers, and personal modifications are allowed. Obviously redistributing any of that code, even my own modifications, would not be acceptable and would violate the license.
You mentioned that the goal is to make the Gold edition features open source eventually, so would you consider going source available?
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#275Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#276Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#277I myself use Paw [0] because it's native to MacOS, but I'm a little bit worried for it's longevity as it being supported by a SaaS business. But so far it's been great to document API for my personal projects. [0]: https://paw.cloud/
Electron looks ugly, it doesn’t integrate, fails to handle HiDPI usually, in best case it eats a ridiculous amount of memory (factor 5x compared to native) and in worst case it has security issues due to Blink and lot of JS.
Electron is Flash for the Desktop.
Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#278Re: Bruno: Fast and Git-friendly open-source API client (Postman alternative)
#279Earlier quoted context omitted.
The unknown length isn't much of a problem for me in practice: GPT's are slow enough that getting a large chunk is almost impossible. I like the idea of the C filter, but in the end you're just piping the data to the program, why add the middle step? Is it to protect against too-large chunks in some way? I don't know a public API that returns JSON slowly, but you could simulate it by just taking a JSON string, splitt…
"I like the idea of the C filter, but in the end you're just piping the data to the program, why add the middle step?" 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,…
> 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.