[HN Gopher] Show HN: Lama2 - Plain-Text Powered REST API Client ...
___________________________________________________________________
Show HN: Lama2 - Plain-Text Powered REST API Client for Teams
Hey everyone, I've been working on publishing _Lama2, a Plain-Text
Powered REST API Client for Teams_ , for the past few months.
Initial work on Lama2 started after my dissatisfaction with
existing tools such as Postman/Insomnia. I wanted a text-powered
and git-friendly system with a lightweight GUI layer on top so that
I could onboard beginners/newcomers quickly into my team while also
maintaining control over data. Today, we use Lama2 extensively
internal to Hexmos; almost every internal code review tends to have
a `.l2` API file attached now. It has worked great for us. More
about the approach with Lama2 below. TLDR: - Approach: "Markdown
for APIs" (Design philosophy -
https://hexmos.com/lama2/reference/philosophy.html) - Store APIs in
plain-text files in human friendly syntax. (Examples -
https://hexmos.com/lama2/tutorials/examples.html) - Simple CLI to
execute API files - VSCode extension to launch requests right from
within your editor - Collaborate with team over git - Good
documentation + Extensibility - Import from Postman into Lama2
files - Fun Implementation :) Hand-crafted recursive descent parser
in Golang; integrated flexible JSON parser Links: Documentation
site: https://hexmos.com/lama2 - Github:
https://github.com/HexmosTech/Lama2 Background story: The story
begins more than a year back, when our team at Hexmos wanted to
collaborate on APIs in a simple and straightforward way. Our
engineering infrastructure is split into dozens of self-contained
software services. We deal with 100s of internal APIs, and so felt
a need for a robust workflow for defining, sharing and updating
APIs within our teams. Traditional solutions such as
Postman/Insomnia implement the collaboration features within their
applications, and also tend to charge a fee for collaboration. We
felt using git is the right way to collaborate on APIs, rather than
any custom built solution. So, in a matter of 2 days we got a
regex-based prototype DSL language to store API files. Lots of
issues cropped up over time, but we kept making improvements to
Lama2 as needs arose. We accumulated 100s of API files over time.
Then, we decided that the tool deserves to be out there, benefiting
teams that want to collaborate on APIs over git. So, to make it
happen, first we invested into formalising the grammar, and
implementing the DSL as a hand-written recursive descent parser.
Then we invested into helpful documentation, demos and so on. Once
we had the basics, we released Lama2 into the world. Future tasks:
- Create human-friendly syntax for specifying websocket APIs, basic
testing, etc - Integration with more editors + deeper/richer
integration Any suggestions/criticism/feedback welcome :)
Author : atomicnature
Score : 30 points
Date : 2023-01-01 14:06 UTC (2 days ago)
(HTM) web link (hexmos.com)
(TXT) w3m dump (hexmos.com)
| user3939382 wrote:
| The JetBrains IDEs have a similar feature (text based REST
| client). It's got a ways to go but has also come a long way, you
| can see from the patterns in release notes it's a focus for
| JetBrains. I can't wait for it to mature. For this purpose, text
| configs >>> a GUI like Postman. IMHO even more so when tightly
| integrated with the IDE/debugger/etc.
| atomicnature wrote:
| JetBrains - good mention, it's a move in the right direction. I
| too am eager to see this space mature.
|
| I am strongly in favor of text config + lightweight GUI in
| multiple editors/IDEs; that's the underlying idea with Lama2.
| Just as in the document markup space, there is room for
| multiple solutions with slightly different application areas
| here as well.
| sa46 wrote:
| I've been meaning to start using JetBrains http files as
| integration tests with their recent free-as-in-beer jar [1].
| There was also an open-source Go implementation floating around
| that I can't find.
|
| [1]: https://blog.jetbrains.com/idea/2022/12/http-client-cli-
| run-...
| robotroll wrote:
| How does this compare to https://github.com/Huachao/vscode-
| restclient
| atomicnature wrote:
| Lama2 probably will never have as many options/complexity as
| this extension. For the following purpose.
|
| If I add an intern into my team, I want them to "get" what's
| going on with APIs without many reference docs. So it has to
| pass real "intern tests".
|
| Second difference is: I want to keep the "language" and
| "extension" utterly separate. In fact, I want `l2` support in
| multiple editors; VSCode is just a start.
|
| Third, I have a rudimentary Postman import, which preserves
| original hierarchy/organization. My focus is to get the basic
| features of Postman with similar ease of use, on top of a
| lightweight UI. (maybe 20% of Postman's features; not more)
| [deleted]
| newusertoday wrote:
| have you checked this https://github.com/federicotdn/verb . Its
| emacs package and i am able to write and test api's with text
| files.
| atomicnature wrote:
| Yes, I've seen the documentation for this, although I
| personally am not a emacs user, neither are my team mates.
|
| With Lama2, my approach is to separate the language from the
| various editor extensions. Keep the language simple/lean and
| then build extensions/integrations to different text editors &
| IDEs on top of the core.
| ushakov wrote:
| Does this support request chaining?
| atomicnature wrote:
| Not yet, for the following reason.
|
| I do not want to import xpath/jsonpath syntax as is.
|
| My goal is: if a new intern joins my team, I don't want to send
| them 3 reference docs (for lama2, xpath and jsonpath) just so
| they understand what's going on with APIs :)
|
| So I am still musing of ways to get some sort of chaining,
| without complicating the syntax. Implementation is not the
| problem, but the right level of complexity (a.k.a does this
| pass the "intern test"?)
| zodvik wrote:
| How does this compare to hurl.dev?
| atomicnature wrote:
| 1. hurl.dev seems to do a lot more, with a focus on
| testing/CI/CD. I am focusing more on simplifying the
| request/response flow alone. I primarily care about interactive
| usage. IMHO, tests and CI/CD are better done through project
| languages, such as Python.
|
| 2. hurl.dev seems to focus less on team/collaboration aspect.
| For me, the first and foremost usecase is onboarding new
| teammates, ability to link APIs in code reviews, finding diffs
| in API, etc. Ease of use is paramount. So, I have developed a
| _VSCode extension_ (https://marketplace.visualstudio.com/items?
| itemName=hexmos.L...), and want to focus on developing
| integrations with various other editors as well.
|
| 3. Another agenda I have is to develop good documentation and
| communication around a Plain-Text based API workflow for teams.
| I believe explicitly explaining how a Plain-Text + Editor GUI
| workflow can remove the need for expensive solutions is an
| important point.
|
| 4. I believe the syntax for hurl.dev is not exactly "memory-
| friendly". Example: HTTP/1.1 200
| [Captures] csrf_token: xpath
| "string(//meta[@name='_csrf_token']/@content)" #
| Do login! POST
| https://example.org/login?user=toto&password=1234
| X-CSRF-TOKEN: {{csrf_token}}
|
| I am resolved to keep the syntax simple/readable first and
| foremost so that I can onboard new people into the language
| real fast, with less dependency on repeatedly referring to
| documentation.
|
| 5. Lama2 is implemented in Golang (while hurl is in rust).
| jicea wrote:
| Hi, maintainer of Hurl here [1]! We try to make a really
| simple syntax while enabling passing data between requests. I
| find Hurl syntax clean, but beauty seems to be in the eye of
| the beholder... Good luck with Lama2!
|
| [1] https://hurl.dev
| atomicnature wrote:
| Apologies if it came across as an attack -- emphasis on "I
| believe" :)
|
| In text markup as well, there exists a wide range of
| options to choose from. MD/WikiText/AsciiDoc/reST/BBCode
| etc. Each seems to be optimised for slightly different
| contexts.
| jicea wrote:
| No offense! I really think there's a strong need for a <<
| Mardowned >> HTTP format, for documentation, tests etc...
| Lots of good solutions, Lama2 included.
___________________________________________________________________
(page generated 2023-01-03 23:02 UTC)