Especially once a VC gets into the fold.

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

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.

They haven't.

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.

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.

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.

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://github.com/RESTEDClient/RESTED

You'll never guess who makes it.

(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`" ..

Not to mention, that bru syntax looks really nice.

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).

How do you know it’s not a great experience?

0: https://github.com/diepm/vim-rest-console

What’s not acceptable is the rug-pull of presenting something as free and trying to claw back money from the endeavor after you’ve got users locked in. If you need money, don’t offer a free product. If you offer a free product, make sure you can afford it.

No one is going to judge you for charging the worth of your offering. However, you’re also not going to get free goodwill and advertising for no reason.

Spend your time and energy wisely, that is your personal responsibility.

I will likely buy Bruno because it is a one time fee and I control my data. It should work forever after that.

Postman's problem is they took hundreds of millions of funding that somehow thinks an API request tool is worth $5.6 billion (though I'm sure that's waaaaaaaaaaaaaay down from the 2021 ZIRP frenzy). So now Postman has long since gone down the full enshittification path with a totally unnecessarily complicated UI and authentication and cloud features that hardly anybody really wants.

I like Bruno simply because I believe their approach is much better: simpler UI and, importantly, as their demo video points out, collections of API requests can be saved in an easy-to-understand format in git. Much better than some proprietary cloud storage.

They can run whatever they want. I, and the parent, wont be using it.

Bruno has a paid option too, btw, and I'm fine with that. I'd be fine even if it was the only option. Login and extra BS features to tie me in? No, thanks.

[1]: https://hurl.dev

Takes slightly longer the first time than curl or Postman. But much more powerful in terms of using in scripts for operations tasks.

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.

Some similar ideas - actually treats the file system as authoritative, runs locally, can share collections via source control with teammates. Difference in this case is that I used Lua as a lightweight scripting layer that I gave all my necessary tools to. So now I have a HTTP toolkit, and some for Kafka as well (which I use a good bit). I’ve been able to use it to replace all my API testing and development, as well as perform some more involved migrations and some dashboard-like actions (e.g. can list out resources and then check failures for each of their IDs).

It’s also just a single binary with the web UI and CLI bundled in, which works more for me. Still early days for the little tool, but hoping it could be helpful for someone else.

I've been using it for a while and I really like the offline first + git collaboration aspect of it. Only missing Websockets functionality at the moment.

Postman dug its own grave after selling out itself for VC money. The “File over app” philosophy is a direction that we should be supporting after the Post-ZIRP VC money world.

1: https://stephango.com/file-over-app

It should also be easier to comply with GDPR’s Right to Data Portability (article 20) for applications that follow the “File over app” philosophy.

1: https://www.edpb.europa.eu/sme-data-protection-guide/respect...

[0]: https://paw.cloud/

postman is really bad, nobody should use it. same goes for similar solutions, even this one.

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.

It is exactly the opposite of flash.

Which I disagree with and provide my argument to show that any technical inconveniences parent poster noted, are not enough to say “Electron should be trashed and razed out”.

Discord the Electron app uses 1.2 GB of RAM.

Ripcord the compiled client uses about 30 MB of RAM.

That's a factor of over 42 times.

Of course you could also just check in to version control these requests as curl commands, so if your team has the technical knowhow, that's about almost the same.

Or even better, you write some tests in your language to make these requests, then you have an integration test, too.

1. Easier to organize collections of requests in a visual hierarchy

2. Environments mean you can use the same collection to easily execute against local, dev, staging, production, etc.

3. Pre- and post-execution scripts mean you can programmatically extract values and chain into other requests (think grabbing an access token from an oauth request then using that token for an authenticated request)

It's basically just convenience features, nothing you can't get with other tools.

Sometimes, you have to find out how an API works, exactly. Sometimes you want to test your own APIs in ways the regular clients do not allow.

Iirc Bruno does not have enough environment/variables/pre-post-request scripting support

If you're really comfortable with all those tools, you won't understand Postman because you'll say "why don't people just chain all these tools together?". It's like the famous hn comment on dropbox, "why don't people just use rsync"?

It's technically true, and if you're adept at those tools, you should probably use them instead of Postman. But yea, it's a useful product for a bigger set of people.

https://github.com/usebruno/bruno/discussions/269

I.e. something that I can query via curl or via a network library that I’m using, and see in response what kind of request it actually received. It helps me verify that I’m making correct requests (and not misusing curl or a network library).

Currently I google for that and use the first online result that comes up. Is there an open source local equivalent, or does Bruno offer some solution for that?

If I also want control over the responses (e.g. return a 401 status code for every fifth request), I have a custom extender script [2] for that.

[1]: https://www.zaproxy.org/

[2]: https://www.zaproxy.org/blog/2022-09-13-zap-extender-scripts...

    <?php
    print_r($_POST);
    print_r($_GET);

[0] https://www.mock-server.com/

> I.e. something that I can query via curl or via a network library that I’m using, and see in response what kind of request it actually received. It helps me verify that I’m making correct requests (and not misusing curl or a network library).

Did you consider using a proxy during development. A man-in-the-middle server that does nothing but relay and record all communications between client and server?

I made one specifically for this use-case. See it in action (3m video): https://www.youtube.com/watch?v=kpsFSY-G5F0

I wanted to use hurl (https://hurl.dev/), but Bruno's UI seems to be useful while developing the tests... Has someone tried both ? Which is better for automated testing, including when the response type is html and not json?

https://github.com/pashky/restclient.el

It does just about everything you can think of, and since it’s just “a text file”, easy to store in git.

The ability to easily use the output from previous responses in subsequent requests makes for great story demos and/or test cases.

And it’s all done in VS Code, using tools/keystrokes/colors you already know and love. :)

I haven't seen anything being able to compare excels. Also, usually test frameworks are aimed at developers (unsurprisingly), not at testers who might not be comfortable in writing scripts (looking at you, Katalon)

So, what is the utility of tools like PostMan, Bruno and others when one has automatically generated docs with Swagger with which one can interact? As an example, you can check my current project where I have set docs like that (still need to add an endpoint field): https://peacefounder.org/PeaceFounder.jl/dev/schema

How you going to do it in swagger?

And more serious question is how you going to force developers keep swagger up to date so I can execute such scenario?

This is a good explanation. I would however be inclined to do that within a script.

> And more serious question is how you going to force developers keep swagger up to date so I can execute such scenario?

The swagger is created automatically from the routes themselves so it is always up to date. To maintain endpoint an integration test can be written which executes the scenario.

It's not like these sites serve swagger.

Lifetime license does not necessarily equal lifetime updates. 2 years of updates is generous enough for $19.

Any idea if the CLI app is available as a standalone? Looks like its a "desktop app + cli” or nothing deal from what I can find.

I hope Bruno works better in that regard.

It seems like the API QA developer tooling has still room for disruption.

https://www.usebruno.com/about

Here we go again. There are two versions of this tool. One which is "open source" and another that has additional features which are closed source.

Not very "open-source" after all.

Layoff happened, and we didn't yet have our postman software in our list of services to remove employees from. This is not Postman's fault.

One person had "deleted" all his collections and workspaces after the layoff to clear his laptop of all things related to our company. After we got an email from Postman saying our workspaces were deleted, I removed the laid off users. Since I removed the laid off user, the "trash bin" associated with them was also deleted. Postman support restored all the collections but the "environment" was gone. Which was all of our QA test keys, etc...

Our Postman collections are still in shambles after that, and we don't have any employees to manage it anymore. While I totally don't hold Postman accountable - there is definitely a reason why "no-cloud" is a good way to go with these kinds of tools.

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.

Also, using curl and the shell allows you to progressively iterate. So "write a script at that point" was kind of the point. Though you don't need to go that far to just feed authentication info.

GUI solutions don't have endless possibilities. You start and end with the exact same tool. The clicks and form fillings can't easily be copied around and iterated on unlike commands in a REPL. You can only perform tasks defined by the author of the application.

Also expecting end users to develop their own file syncing solution on top of FTP is unreasonable. Expecting software engineers to be able to use curl instead of a GUI form is not.

These tools are Mad Libs for curl commands presented as GUI forms. It does a subset of what curl + shell does while requiring more clicks. The target demographic are people who need to know the tool it's meant to replace in order to do their jobs effectively. That not easier or more convenient in my book.

- Open source

- Text files all the way down

- Easily understood DSL

- Easily distributed

- Easily versioned

- Fast

Download the executable, copy the two lines below into "first-test.hurl" and you're up and running.

    GET http://localhost:3000
    HTTP 200

[0] https://naprun.dev

IMO only thing missing for me is a predicate that checks every item in the array for some condition.

Ultimately settled on Bruno. It's backed by readable text files[2] as well. The CLI works for scripting. And the GUI is familiar enough that I've managed to convert Postman holdouts at my dayjob.

[1]: https://github.com/Orange-OpenSource/hurl/issues/1723

[2]: https://docs.usebruno.com/bru-language-samples.html

[1]: https://hurl.dev

But for sharing requests in a team an app is nice. I had a good experience with Bruno. Bonus point for easy to store configs.

Pros:

- DevEx is great, the experience moving between writing tests through text vs the client is seamless (allows different expertise to collaborate more easily)

- Fast and has all the basic features you’d expect

- Offline first

- Continuous improvements being made

Cons:

- Somehow, if the test fails connecting with the server its a passed test. So watch out for that one! I really hope it gets fixed soon!!

- Would be great to be able to dump the variables after a run through CLI

- Failed outputs from assertions and expects could be a bit more verbose, but it’s mostly likely the result of a dependency I assume

Regarding long term strategy, they seems to have a valid (non subscription based) where you can get some very nice premium feature for a one-off licence price (which is the kind of business model we need to support - instead of the madness we have going today with everything is subscription)

What is required to be considered an "API client"

Perhaps "API client" is "HTTP client" + "JSON parser"

Could "JSON parser" be a separate program

Thank you for the patience. We have been occupied with adding File Uploads and OAuth2 support in Feb and prepping for the Golden Edition release. This issue is priority. Hoping to get the PR merged soon.

Very similar idea as Bruno: everything is configured in text, which I always find myself more productive in that full blown GUI where I need to tab from edit text to edit text to get anything don.

[1] https://www.jetbrains.com/help/idea/http-client-in-product-c...

They are plaintext and can be easily diffed and they don't invent a totally new language.

The extension also supports somewhat esoteric features like client certificates, which I already needed.

So I'd be more interested in a comparison between bruno and .http than insomnia.

[edit: grammar & typo]

There are a few minor features I miss (being able to bulk edit headers is the main one), but overall I highly recommend it.

From there, I did research and found `insomnium` and a coworker found `bruno`. Bruno aligned closer to what I value, so now I use that.

But if we want a Git-friendly text format, why not mimic HTTP/1.1 request syntax as much as possible? Maybe with Jekyll-like YAML front matter for metadata that doesn’t fit?

So for Get Users.bru instead of the current example of:

  meta {
    name: Get Users
    type: http
    seq: 1
  }
  
  get {
    url: https://reqres.in/api/users
    body: none
  }
  
  headers {
    Content-Type: application/json
  }

  ---
  name: Get Users
  type: http
  scheme: https
  seq: 1
  ---
  
  GET /api/users HTTP/1.1
  Host: reqres.in
  Content-Type: application/json

Example:

    GET https://example.com/comments/1 HTTP/1.1

    ###

    POST https://example.com/comments HTTP/1.1
    content-type: application/json

    {
        "name": "sample",
        "time": "Wed, 21 Oct 2015 18:27:50 GMT"
    }

[0]https://www.jetbrains.com/help/idea/http-client-in-product-c...

store REST API requests as files, such that you can git version-control them

may I recommend:

https://marketplace.visualstudio.com/items?itemName=humao.re...

super simple. just requires VS Code.

Im checking out Bruno as well though, looks like a great tool

It’s painful having to do an import/export of the collection from a file every time you want to modify the collection or debug a test, though, and the JSON files are still not entirely diffable/code reviewable even with the guids stripped. But it works - you can collaborate as a team with postman without using their cloud.

But the idea of switching to a tool that actually wants you to work that way is definitely tempting.

Our OpenAPI spec has something like this:

    servers:  
      - url: https://{host}/api/v2  
        variables:  
          host:  
            default: someserver.example

I make requests with it, have things organized in collections, and use a variable for JWT handling but that’s as fancy as I’ve gotten and I know these tools have a lot more depth than I’m using.

Meanwhile, I often dev on iPad Pro with keyboard and trackpad, and instead of Postman, Insomnia, etc., I've enjoyed HTTPBot:

- HTTPBot for iOS: https://apps.apple.com/us/app/httpbot/id1232603544

- HTTPBot for MacOS: https://www.httpbot.io/

HTTPBot even supports postman collections and environments including sync with postman, along with GraphQL, Websockets, and response metrics.

AMEN! I've been annoyed by Insomnia and Postman for a good while for these reasons exactly. My latest client of use, Thunder client VS Code extension also started pulling the same shit, and I'm cutting it off too.

I'm struggling to remember the reason I didn't stick with Bruno. I think it was due to not having an equivalent to Postman's pre-request scripts. If that could be added, I'd certainly give Bruno another try.

Edit: Another comment has mentioned that Bruno now has (or maybe always had and I just didn't see) pre request scripts.

I tried it out; it's exactly what I wanted. Postman, as echoed in previous comments, has gotten out of control with the upsell and the confusing UI.

I bought the pre-order, seems like a good deal at $9, that's nearly the cost of a latte around here and if this works out I'll get a lot more use out of it than a latte.

Postman/Bruno/insomnia all suffer from the 'curse' of web design making it's way into professional tools leading to lower information density and higher 'white space'.

I feel so strongly on the matter is why I started a project that is unfortunately in comatose for the past year : https://nokori.surge.sh/

The design isn't there yet, but I'm aiming for a professional looking information dense UI.

As well, it would be nice to be able to import my rather large postman collections (an vice versa - provide a collection from Bruno to a Postman user).

Looking forward to when I can switch to this full time.

I know snaps are slow, but the Postman snap takes forever (~16 seconds)

I'm sure Bruno is still in the 1st phase of enshittification, but at least with local .bru files we can ensure longterm maintainability.

On the other hand, devs are most likely the stingiest individuals on the planet that expect all of their tools to be free. So I respect the team for even releasing it open source in the first place.

The key thing about Postman is that I was able to configure my own script to refresh the API token. For the internal API, we have a short-lived "access_token" token (~1 minute) and then a long-lived "refresh_token" (~1 day) based on the user's email address and password. When renewing the token, you receive information about its lifespan. You cannot create a new scratch token every time because you will be rate limited. I put all that logic in Postman hook script.

Making these HTTP requests in Curl – due to token refreshing – is painful.

Will Bruno support this use case?

  $ eval $(stat -s refresh_token); #set some stat vars, will use change time st_ctime
  $ if [ $(expr $(date '+%s') - $st_ctime) > 86400 ]; then rm refresh_token; fi
  $ if [ ! -f refresh_token ]; then ./get_refresh_token.sh; fi

I believed the standard was created by jetbrains.

https://www.jetbrains.com/help/idea/http-client-in-product-c...

Nice GUI Clients: Postman, Insomnia, Paw (ease of use)

Nice CLI Clients that use plain text files: Jetbrains Http Client, Hurl, Httpie (privacy)

Bruno: The only GUI client with a Nice UI that works on top of plain text files

It's the best of both worlds.

In what way is Jetbrain's http client a CLI tool ? There's also vscode rest client.

There's no need to shortsell other clients. I think Bruno has sufficient differentiators to standout on its own.

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 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

> I didn't stick with Bruno. I think it was due to not having an equivalent to Postman's pre-request scripts.

Bruno has come a long way, we support pre-request scripts and a lot more

> But can it handle oauth2? I had to write a httpie script recently just to test an oauth2 api.

We have released oauth2 support, some rough edges are being polished

> Good thing it's open source. Money being involved, I don't have long term hopes for it's openness.

I understand this is a hard problem. We are fully bootstrapped and independent. We earn money via selling the Golden Edition. We will build more developer products in the long term, and the goal is to make even the golden edition features also open source in the future. I am committed to this cause.

> History goes in circles. New API client appears, adds features, userbase grows. Forced login is added, users are angry and look for alternative. New API client appears.

I have felt this pain. That's one of the reasons why I denied VC funding and chose to remain independent. Having seen 10 years of this cycle, its enough. We don't want to repeat the same saga.

Some good links where I have discussed about opensource, freedom and monetization

- https://www.usebruno.com/blog/bootstrapping

- https://github.com/usebruno/bruno/discussions/269

- https://www.youtube.com/watch?v=7bSMFpbcPiY

We are also working on standardizing and improving the Bru Lang to bring more features in Bruno. See: https://www.brulang.org/

If you'd like to pre-order the golden edition: https://www.usebruno.com/pricing

Thank you for all the love and kind words, HN!

The real Bruno looks like the logo too :) https://www.usebruno.com/about

More places need a CJO!

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?

And a question: can you share your plans about Vscode extension? It seems to be broken for a while, do you have plans/capacity to revive it?

  - The need for multimaps to represent duplicate keys
  - The need for annotations to ascribe additional information about a key-value pair

Its really not clear what features like:

- "Performance/Load Testing"

- "Load Data from File for Collection Run"

etc..., are since there is no mention of those in either an upcoming features page or documentation.

* web app: https://restfox.dev/ * repo: https://github.com/flawiddsouza/Restfox

However I recently learned that it also has web and desktop client apps which are pretty great too!

https://httpie.io/

Then I found Bruno and fell in love. Thanks for the great work!

Can't say I really miss it. I personally prefer just using a jupyter notebook for these kinds of tasks. With a custom tool like this it becomes a dead end with the data. Maybe you want to decode it if it is on a binary format. Or you want to plot some basic stats?

I’ve just switched to using hurl. Can’t be bothered with any of this nonsense with all these GUI programs

I never quite saw enough value in tools like postman. Usually either what you are doing is trivial enough for vanilla curl or complex enough to warrant reaching for a general purpose programming language.

Instead, I just hacked together a small Python library, called all the APIs from there, and pushed to Git. Everyone on my team understands it, I have 100% control, and no cloud needed.

Not sure if you're referring to Postman or Bruno. The biggest purported benefit of Bruno over Postman is that it saves API request collection files in simple, human-readable text files that are designed to be committed to a source control repo and easily shared, in a way that's not particularly tied to the Bruno app.

The demo video explains in detail: https://youtu.be/b_ctmKlEOXg

I don't have time to look at a 15 minute marketing ("BILLION dollar") video. Is it available in text form?

Does Bruno decode e.g. AVRO or protobuf? Connect to a schema server?

What is considered "human readable"? A JSON file like postman?

Could you elaborate what is the benefit of using this tool compared to a REPL/notebook?

Are you affiliated with Bruno?

I didn't know about Bruno until I saw this post on HN.

As i pointed out i am content with my solution. The one you were originally replying to. Replying - not in content but threadwise.

You don’t care enough to read the manual, but clearly care enough to ask a bunch of questions that could have easily been answered by yourself with a modicum of effort. The home page even has an example of the file format, is even opening the page too hard of an ask?

Did you just want people to do all the work for you to “convince” a random stranger? In what world is that reasonable?

I guess my take was what was his reason for answering what I initially posted if all he wanted was to RTFM me?

So I turned to Bruno. I have been happy with it but there are some strange issues. Sometimes it does not save settings when I press Ctrl s. I still don't know when this happens but I lost some work a couple of times because of this.

I hope Bruno has support for separate environments and environment-level variables soon because the ability to set global variables along with environment-specific variables/overrides makes the setup much more manageable (I think there is a feature request already open for this).

PS: if this possible via some sort of external JSON/script, I am more than happy to set that up. I am just not familiar enough with Bruno tips/tricks :(

The fix for me: cmd+s only works if the left pane (Query, Body, etc) has focus

Save does not work if the right pane (Response, Headers, etc) has focus

I don't have much of a problem with that. Heck, looks like Bruno has multiple tiers that they sell the product for, and it looks like a very reasonable way to make money.

The problem is this idea of "infinite growth" that modern markets demand, which results in the eventual enshittification of nearly all tech products these days. Postman could have had a very nice, reasonable business, but once they took an obscene amount of funding (nearly half a BILLION dollars, for an API client tool!!!) their fate was sealed. Beyond taking too much money, Postman clearly thought they had a much bigger moat than they actually do.

- chain requests passing data from a request to another,

- add tests on every responses: body, headers, certificates, etc... You can use JSONPath or XPath for example,

- there is some sugar syntax to construct request bodies (GraphQL body is annoying with curl, JSON etc...),

- there is some sugar syntax for retrying requests on asserts, delaying requests etc..

Under the hood, Hurl uses libcurl so a lot of curl's options are exposed through Hurl (and we benefit of a lot of curl features like HTTP/3, IPV4/IPV6 etc... and speed and reliability of course!).

(I'm one of the maintainers)

> Hurl can run HTTP requests but can also be used to test HTTP responses. > Different types of queries and predicates are supported, from XPath and JSONPath on body response, to assert on status code and response headers.

This should've become the standard by now.

SoapUI is great.

"I know developers never pay, but why?"

Why pay when there is a free, open and, if need arises, hackable alternatives ?

Developers do pay when there is value is. See how profitable cloud hosting is!

I think in cases like postman, people don’t like when features they previously had used for free suddenly comes with a price tag; rather than innovate and create new value that is worth paying for, some companies are opting to take away features user previously had. Yes, they own/control the software and want to make money , which fine, but they created a dissatisfying user experience as they tried to coercively move users into their cloud offering, wether they wanted to or not, and regardless if it provided user value. After they did that, they shouldn’t be surprise a portion of their user base decide to ditch the product and complain about the experience. This is compounded by the fact that they leveraged the contributions of an open source community, and at the same time there are other options freely available that aren’t locked into a proprietary cloud login.

Productivity tools better to be lean, simple, free & open source in some cases. This is one of those.

Of course, you can keep throwing money at bulky software continuously making things slower and more complicated, just because you never have to worry about money thanks to the VC money. I’m old enough to not buy that this is how startups operate in general though.

The new entrant maybe has lower internal costs or subsidises the price initially, but it does not mean that one provides more value than the other.

In the Bruno case, it sounds nice with open-source, free for the basic features etc, but it's not much different than any other freemium offering. They will also try to make money on premium features and other related tools. Their own development time will be spent on those features and they will outsource a lot of the development of the base tool on the open source community.

Bruno is not free. It has a free version, but you can pay to have more features.

The game was up for Postman when I realised I could replicate all its functionality I needed by asking ChatGPT to write me some Perl scripts that made heavy use of LWP.

Usually in organization it is much easier to just increase the spend on already approved vendors. Increase the AWS spend by $50/year? Nobody is going to ask you about it. Or start using some tool that does not involve payments - nobody even knows you are using it.

It would be great if we could change that. A world where independent software developers could make a decent living by selling small quality tools would be a better place.

Being non-free is a defect that can always be improved, best technology is always free and something you don't need to think to use.

I paid for a physical copy of an explanation of the method; now I'm free to use the method in my drawings or share it with other people.

That would be great

It was nice to find out about the for-pay golden edition in this thread to support Bruno’s efforts. The feature split for free vs Individuals vs Organizations seems well done.

As feedback to the Bruno team:

for Individuals - I most value the gRPC/websocket, then load-testing

for Organizations - My org would most value central license mgmt

Perpetual license - nice. I do not buy software subscriptions for my development tools. Only perpetual. In cases like Postman - sure I'll take free version but I was holding off from doing anything serious with it.

All data local only - even nicer.

Ported couple of requests from Postman. All works.

Congrats. Unless I hit some stones during testing I will be buying license when available

Most likely Postman will go to trash bin very soon

It is cool so far. I like that it is more git friendly. I have noticed an increase in request time which is interesting. I assume because postman caches more stuff.

[1] https://github.com/usebruno/bruno/pull/1217

I feel like this should be possible with today's tech, but am coming up dry finding anything while searching.

Can someone help me understand what is meant by this API can be mapped to folders & files comment.

https://www.usebruno.com/blog/the-saas-dilemma

Interesting talk about Bruno by the founder about Bruno! Includes its naming origin (very nice btw), the philosophy, a brief demo and overview of the architecture, with a couple of interesting surprises at the end. Is a good watch!

Keep up the great work!

https://star-history.com/#usebruno/bruno&Date

[0] https://kreya.app/ [1] https://github.com/fullstorydev/grpcui