- Free and Opensource IDE for exploring and testing APIs
- It is lightweight with MIT license
- Bruno stores your collections directly in a folder on your filesystem
- Use git for collaboration
- No cloud sync. Fully offline.
PS: I am the creator of this project
There is some missing polish (like missing utilities in scripts or buggy drag-and-drop) and a couple bigger things like no authorization schemes or code export, but the killer thing it has over pretty much all the competition is the JS glue code AND first-class VCS support. Even insomnia had garbage-tier glue code support, something that was very much missing coming from Postman.
Great work!
In every other tool, they treat a collection like something that can be modified only via GUI. In Bruno, its more of a developer mindset. Even if you don't have Bruno GUI, you can open it in an editor and make changes to it - just like code
External npm package installation is unique to Bruno and afaik no other tool has this.
Yes Auth is a big task that I am working on. Glad to see that some folks use scripts and directly implement oauth2 https://github.com/usebruno/bruno/issues/178
Many users are surprised when they find this capabilty, It opens up a lot of possibilities - https://github.com/usebruno/bruno/issues/233#issuecomment-17...
starts as offline
vc funding
enables cloud sync for collaboration with teams
deprecates offline as scratchpad
deletes scratchpad
Its been like this for a decade now.
With Bruno the key insight was to store collections and requests as folders and files, and design a markup language that makes it easy to collaborate with your team. I wrote about this here: https://www.usebruno.com/blog/the-saas-dilemma
First was break a giant collection json and save it as individual files, second attempt was to convert into a dsl (was a bit like xml), the third attempt that is used today to make it even simpler.
The key driving force behind the language design was to make sure that it was simple and readable enough to be able to do a PR review flow in git.
Also, simple enough so that you can open the collection folder in a editor (like vscode) and still be able to make changes
Json didn't support multiline strings. Yaml was indentation hell. I wanted something neat, no need for quotes around strings. And lot of nuances, like how do you store a query param as disabled.
you can read more about the lang design at: https://docs.usebruno.com/bru-language-design.html
What we need is a better approach. One that doesn't involve VC funding. One that keeps the all the incentives of the community, contributors and the creators aligned.
Will share a draft of this approach soon (likely tomorrow) and open it up for community discussion. I want Bruno to be there for the long term.
I have penned down some thoughts: https://github.com/usebruno/bruno/discussions/269
Would love you to hear your thoughts and perspectives.
Sometimes, I wish that I am a billionaire, so that I could let people using my software for free, completely. And the key point is, they know that it is free, absolutely. Because I am a billionaire, they know.
So, just keep it up. Anything you wrote is not important than the thing you do. Don't let people sink you in their perspective about the world they saw.
Open-source software needs a ton of efforts, tears, bloods. Above of the passion, you know that it should be pay-off, fair-price at least, for you and your people hard-works.
At the end, plan is just a plan. Just go to have a chance to fix it.
Good luck and best wishes!
There is telemetry. And I didn't find opt in or even opt out code.
> lightweight
Could you quantify? I never saw a lightweight Electron app.
yes, its miniscule. one ping (and that too once in a day) that indicates that an anonymous user opened the app. No other usage details, micro interactions or anything else is tracked. Sure - in the future we will provide option to turn this off too.
> Could you quantify? I never saw a lightweight Electron app.
relatively, compared to the other electron monsters out there. You are definitely not going to native performance and fluidity, but it's a tradeoff that I made to support multiple os.
Also, currently Bruno is just me developing it for the last 2 years. Recently a community has formed around (nice to see) and we have a flurry of new contributors.
Telemetry is set up here: https://github.com/usebruno/bruno/blob/main/packages/bruno-a...
It uses next.js config which is here: https://github.com/usebruno/bruno/blob/main/packages/bruno-a...
I don't know when this is evaluated, but it seems like if you set ENV=dev it should disable it.
In the last 5 days, Bruno received 25 PRs. I've already merged 21 of them and shipped multiple releases.
Edit: And good luck, I have looked quite a bit for project like that.
I built the tool for myself, I wanted my collections to co-exist alongside my backend code and be able to version it via git. So I ended up creating a human readable markup language to represent requests so that we can use git to version it.
I hope you like it :)
- Is there a way to handle secrets outside of this flow? - Can we set/reference variables between collections? collection A sets a variable, collection B uses it.
also, a small bit of feedback from someone that briefly played with Bruno this morning.
- moving requests in a collection via drag/drop isn't obvious and it's actually a pain if you're trying to replace the top item. - if I duplicate a request I want the new request highlighted and I would personally prefer if the same tab was opened
yes, ALL IN on git :) based collaboration
> Is there a way to handle secrets outside of this flow?
Check: https://docs.usebruno.com/secrets-management/overview.html Two ways of handling secrets.
> collection A sets a variable, collection B uses it.
In bruno collection is the first class citizen, environments reside inside a collection. There is plan to support global environments for the use case you mentioned.
> moving requests in a collection via drag/drop isn't obvious and it's actually a pain if you're trying to replace the top item.
yes, this ux needs to be improved and there is a bug in drag and drop which should be fixed.
I'm guessing your recommendation for dealing with separate environments (dev/qa/etc) would then be a single collection with folders underneath and environments defined w/i that collection.
In that sense collections for bruno seem to be more akin to "projects" and are not really equivalent to postman collections in that sense.
That's workable, it good to know the environments are collection specific rather than global.
if you rename a collection with existing requests in it, the result will be two collections, 1 with the new name and 1 with the old name. The new name will have all the requests as expected.
The old name will be a "ghost" collection, you can't seem to do anything with it, including rename it again. If you close bruno and re-open, the old named collection will be gone.
> if you rename a collection with existing requests in it
I am assuming you are renaming directly using the filesystem. I think this is the is issue you are talking about - https://github.com/usebruno/bruno/issues/28
I am curious: why the request to support OpenAPI turned up only 2 weeks ago? In my bubble it is an ubiquitos format where everything starts and from where any additional data added up.
We don't talk about Bruno.
/S
Sorry, couldn't resist. :)
We don't talk about bruno.
BTW, GRPC will be supported soon. Will create a roadmap section in the docs.
May I ask why .bru? I would really recommend using a standard format. https://xkcd.com/927/ etc..