Replies: 9 comments 17 replies
-
I'll perhaps write a more detailed blog about this decision in a lot more detail later. But here is a decent summary. I can assure you that I thought through this for months, because I knew that once you design a DSL, its pretty to hard to migrate stuff since we directly write to filesystem. Data format migrations are easier if its a hosted solution where your data is sitting in a database How complex can it get?At first glance, when you just think about Easy pr reviews via git for collaborationThe goal was not just to write to a file, but to be able to do a PR review flow in git. This meant that the plaint-text representation of the request had to be simple and easily readable enough to be able to do that.Also, simple enough so that you can open the collection folder in a editor (like vscode) and still be able to make changes. I look forward to the day where it becomes a norm for developers start storing api collection in their source code itself. So that anyone who clones the repo can bring the service up and start playing exploring the api. And athen continue to maintain the api collections just like code. Lang iterationsThe language itself went through many iterations.
@ajaishankar played a crucial role in helping me design the lang. Why not JSON/YAML ?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 represent a key-val paid as disabled in a single line". Like it was quite nice to go from headers {
content-type: application/json
accept-language: en-US,en;q=0.9,hi;q=0.8
}
headers:disabled {
transaction-id: {{transactionId}}
} To headers {
content-type: application/json
accept-language: en-US,en;q=0.9,hi;q=0.8
~transaction-id: {{transactionId}}
} ParserBruno DSL is built on top of Ohm Once you wrap you head around it, Ohm is really powerful. Github issue for reference: #82 |
Beta Was this translation helpful? Give feedback.
-
Another cool thing Bruno's architecture is that the entire frontend app does not know anything about Bru Lang. There is beautiful abstraction built where the frontend app just knows about the JSON representation of the collection. This tiny file is responsible for the And then have a field in {
"version": "1",
"type": "collection",
"lang-parser": "della"
} We likely won't have to, but its cool to know that we can. I realised it when I was able to quickly move from brulang v1 to v2 to v3 without touching the frontend app. I just had to write a new parser and a new serializer. Wait Wait WaitAs I think now, we could support option for people to choose either PS: Della is Bruno's girlfriend :P. |
Beta Was this translation helpful? Give feedback.
-
Other than a tilde (a UI concern) that has crept in, the DSL is nothing but some named sections which are either
One of the goals was to avoid quoted strings and make it easy on the eyes. I appreciate the fact that @helloanoop created a parser for this and it would help in a syntax highlighted editing experience. But a hand written one for this format is also really tiny and simple. For an alternate format, would love to see how complex requests look in TOML |
Beta Was this translation helpful? Give feedback.
-
I really like Bruno, but when I was evaluating it I also felt the DSL too limiting for more complex use cases. For this very reason I am building my own tool: https://github.com/4lejandrito/fetchbook which uses TypeScript as the DSL (see this). Bruno did inspire me to build it. Maybe Bruno can take some inspiration from my little project too :) |
Beta Was this translation helpful? Give feedback.
-
To provide another data point, I have a feeling that the ideas are similar to those behind https://kdl.dev/ ( but no |
Beta Was this translation helpful? Give feedback.
-
@keawade @Jiehong @4lejandrito @dustin-engstrom @lcptrs @blaggacao @lizy-Leeeeee @Napam @ajaishankar @martinsefcik @Its-treason looking for feedback for some updates in PS: Currently improving |
Beta Was this translation helpful? Give feedback.
-
Have you thought about supporting the Jetbrains IntelliJ's Http Client format? Some links if you're not familiar with it:
The spec is licensed as CC-BY-4.0 license. The rest of it is proprietary and closed sourced. I believe the IDE Plugin requires purchasing a license, but the CLI client, while still under a proprietary license, seems to be free as in beer. Since they're also using a plain text file, for a lot of the same reasons that Bruno is, I think that's a hint that you're on the right track. I'm not saying you should just use the IntelliJ format as your format. But it would be cool if it was an option. The use case I have in mind, is let's say I'm on a team that uses IntelliJ and that plugin, and has the files committed to the repo. I'd want to be able to open it in Bruno and just use Bruno. But without "importing" and saving the collection in |
Beta Was this translation helpful? Give feedback.
-
Why not just use javascript files instead of reinventing the wheel? I agree JSON/Yaml have limitations that would be painful in this context, but JS itself doesn't have those problems. Seems like the Bru Markup language could have been avoided just by having exports with expected names (i.e.: insert For example, the sample repo has:
This could have been
Or as functions:
That js function format is nearly identical to the DSL without reinventing the wheel or introducing limitations. A whole DSL to avoid quotes just seems... unnecessary. |
Beta Was this translation helpful? Give feedback.
-
My company are using Thor Client at work, but I would love to use Bruno at home. Then I could change the extension file to .bru and use it directly in Bruno app |
Beta Was this translation helpful? Give feedback.
-
Hey, first off, I love the vision of Bruno as a local-first HTTP client to replace Postman, Insomnia, and co. Thanks so much for building this fantastic tool!
I'm trying to understand what the motivation is for the Bru Lang DSL. I've browsed the Bru Lang sections of the documentation and I haven't found a clear statement for the goals of the language and, particularly, how those goals necessitate building a new language / markup format.
With me not currently seeing the point of Bru Lang, I wonder if it might be better to consider using an existing data format like JSON or YAML with JSON Schema instead of a custom language. In my mind, at least, that approach might be significantly less complicated as it means you wouldn't need to take on the overhead of maintaining a DSL and the associated tooling like parsers, formatters, linters, language servers, etc.
Edit: To add more context, I started thinking about this while trying to apply a bunch of automated modifications to a large collection of request files. I found myself wishing I could work with the data as JSON in JS or even YAML with an AST library instead of needing to do direct text manipulation in my script.
Beta Was this translation helpful? Give feedback.
All reactions