5 ms·
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 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 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 https://hexmos.com/lama2 - Github: https://github.com/HexmosTech/Lama2 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 :)
- deleted 4y ago[deleted]
- zodvik 4y agoHow does this compare to hurl.dev?
- atomicnature 4y ago1. 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.Lama2 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 4y agoHi, 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 https://hurl.dev
- 4y ago