haha

haha the idea comes from the fact that the tool is not opinionated - in the sense that yes its an API client but its also an editor, etc. So it a tool with infinite possibilities and can be as flexible as people want. So this is the idea: void-endlessness-freedom.

If it didn’t scare you alot, will you try it? :)

obsidian, sentry, Voiden (for API work, open sourced it)

interesting. what is the tool that the company accepts as low risk? Would it be postman or would it be something offline?

try https://voiden.md/ (not.app)

does it work?

oh. whats the security error?

thats awesome - let us know what you think when you try!

Our team lives in Git, our communication is happening on slack, our docs written and maintained on confluence and after some time they always drift away from the actual requests inside Postman.

So we built and open sourced Voiden a few months ago: an API tool where all that: specs, tests, context and docs are always together in the same executable plain text file (markdown). We also made this Git native so that every change is versioned and tracked just like code.

The last change we have made is to add a Runner so that one can run the files directly from the terminal and CI/CD pipelines.

here is the tool: https://voiden.md/download repo: https://github.com/VoidenHQ/voiden

welcome to try and give feedback!

what do you mean beyond the skill level?

awesome!

depends on the size of your team I guess? Postman used to really be the default API client for serious API testing. https://kaluvuri.com/blog/when-the-category-leader-stalls/

And yes curl is great and is a big inspiration for Voiden. In fact we built it inspired by curl and obsidian.

The problem I see with curl is that real API work is almost never just one request typed into a terminal like some kind of beautifully minimalist Unix haiku. It involves auth, environments, copied headers, reused payload fragments, request chains, documentation, testing, debugging, sharing examples with teammates, reviewing changes in Git, and trying not to break prod because you forgot to swap one token or one base URL.

At that point you can not “just use curl” right?. You use curl plus other things. Curl plus shell scripts, curl plus notes, curl plus env files, plus copied commands from Slack, plus random JSON files, plus tribal knowledge etc etc… Which is fine I guess but isnt it at some point super annoying and hard to collaborate on? That is the gap that I see this tool (Voiden) trying to solve.

So for me it is not “curl vs Voiden.” curl is a low-level execution tool. Voiden is a workspace for actual API work: writing requests, organizing them, reusing pieces, documenting them, testing them, versioning them in Git, and not duplicating the same headers/body/auth setup 45 times :)

does this resonate?

what do you currently use? what are the limitations of what you tried and were not happy with?

yeah, around 11k installs so far - and a few committed and opinionated contributors :) - hope you give it a try.

Removed by mod

Hey yes will do. Flatpak is something we see considering/working on.

Notion in the sense that it adapts to the user. We like this idea : that you can use Notion for literally Amy document you want.

In the same way, when one open Voiden they can “program” the interface with slash commands and add headers, auth, documentation etc in any way they like. So in Voiden we bring specs, tests and docs together in one single file. In the same way that you can use notion to bring different lists, blogs, ideas etc into the same place and collaborate. The difference and the power of Voiden is that everything you add in the Voiden doc is executable, meaning you can run the tests in the same place and keep the docs and the context (that might be on slack or anywhere else devs talk) together.

Basically the notion like refers to the philosophy of the tool to not force a fixed UI to the user and allow for different use cases and scenarios. Does it make sense?

We are also calling it Lego for APIs for the same reason plus because of the fact that you can use blocks to compose requests but also reuse them for multiple requests that share some similar components.

cynically true :)

yes thats a good idea, we actually made an FAQ that sits with our docs…I want to monitor to see if this helps people navigate some of these questions:)

hm…great points, thanks for taking the time to answer.

From the perspective of a user, why would they care about development speed?

Yes, the tool is already developed but it will continue evolving right? I mean, we almost make 2-3 releases every month since we shipped the first version and then open sourced. So the speed still counts. Plus, the users who create the tickets and expect them to be tackled are actually developers themselves. So yeah, the ability to deliver (at a good pace) to these folks matters a lot.

However - YES, if at some point the tool is at a state that the speed becomes less meaningful or useful, then indeed a change might be needed?

As for platform consistency, again, why would the user care?

Yes, since our users are Dev (and QA) folks, we thought that yeah, maybe someone could have different systems for work vs home vs side project (as you said). But another aspect that we thought is teams and collaboration. We didn’t want to have a scenario in which a team can not use it before some of the devs are using macs, others linux vs the QA folks using windows etc.

What I’m getting at is that the concerns of developers will not always be equally concerning to users.

Thats the heart of the discussion:) I guess because our users are also developers. :)

nice metaphor:) but unlike a car, these Electron processes aren’t slowly eating your tires or draining your oil. Maybe a better metaphor would be that the car you rent comes with a few extra cup holders you that you didn’t ask for? :)

thanks! well, the feedback and the questions did not come from lemmy per se but in general. And yes, I agree with you. People do have strong opinions and this is more a question for me - as I often feel that perhaps there is some “better” way to explain or show the impact of the decision. (and explain the trade off). But I think that ultimately you are saying one simple (but very important) thing: that you can not please everyone :)