Spyke

Replies

Comment on

Modern API tools

Reply in thread

haha indeed - modern has this "blinking lights" connotation. something that is shiny.

True story - once, in primary school, I went to a halloween party, where all the boys were dressed as batman and all the girls as macarena (guess my age). The host of the party was maybe the only one not dressed as batman.

He was wearing some weird jell in the hair, like a punk kind of thing, with a lot of strass, stars all over his body, some heart or thunder shaped big mirror glasses, a shiny jacket and the best looking blue mocasines I have ever seen. He also had a big radio antenna (??) coming through his nylon electric yellow vest.

I asked him: what are you dressed as? and he replied: "Modern".

Comment on

The API Tooling Crisis: Why developers are abandoning Postman and its clones?

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!

Comment on

Voiden - A Markdown based Open Source Alternative to Postman

Reply in thread

hey, nikolas here (part of the team of Voiden)- I am keen to understand more if you dont mind. Which of the preferences you mentioned discounts this project? the version control and lightweight?

I guess you are you referring to the tool being on Electron (Since the version control is handled through the native git integration)?

We used electron cause allows to deliver the same experience across Windows, macOS, and Linux, and makes it easier to iterate quickly in these early stages.

a few points:

  • Some apps do feel heavy because of how they are structured : monolithic cores, always-on cloud layers, or unnecessary background services. Voiden is (intentionally) built with a lightweight core: offline-first, Git-native, and without extra baggage.

  • Voiden uses a plugin architecture. This means that we have a small core and all the extra functionality is optional (users can enable or disable plugins) so the base app stays small while the ecosystem can grow. Community contributions or advanced features don’t inflate the core, they live in plugins that users opt into.

At the same time, there is no special tie to Electron :) We evaluated other options as well but we felt they didn’t offer the same support for all the features we wanted to deliver.

But we intentionally designed the plugin SDK to be framework-agnostic, leaving the door open to switch the core to a different framework in the future if it makes sense.The goal is a tool that stays lean, extensible, and adaptable as it evolves.

apologies for the long answer - hope it makes sense?

Comment on

Modern API tools

Reply in thread

this is the "joke". that every API client calls themseleves modern without this essentially meaning much.

and certainly not, I dont mean Postman. But this is the easy answer. What I also mean is that many of the tools that came as a response to Postman being "old fashioned" are basically mimicking the same things or principles with a few things here and there.

so everything is like "postman but with a better XYZ feature" or "Postman but open source"...

Comment on

Voiden - A Markdown based Open Source Alternative to Postman

Reply in thread

I actually agree with most of your premise.

Voiden is not coming from “people are too scared of the terminal, let’s save them with buttons.” It comes from almost the opposite direction. A lot of us are terminal people too. The problem is not that curl, hurl, scripts, OpenAPI, or plain code are bad. The problem is that API work tends to get fragmented across too many places once it becomes real.

You have raw requests in one place, auth logic in another, docs somewhere else, examples in Slack, test cases somewhere else again, and then different teams consuming different versions of what is supposedly the same API. That’s the mess we care about.

So the goal with Voiden is not to replace power-user workflows but to give them a better structure, while also making that same source of truth usable by the rest of the team, including people who are not living in the terminal all day, or simply have different preferences.

That is also why composability matters so much to us. Reusable headers, auth, query params, payload fragments, shared blocks, documentation alongside execution , not because curl cannot do requests, but mainly because nobody wants to maintain the same slightly different request 100 times across scripts, docs, and collections.

And on the “UI tools become dead ends” point: yes, that is the trap we are trying to avoid. We do not want a bespoke black-box UI where if there is no button, you are stuck. The idea is to have one source of truth that can still work for power users, can be versioned in Git, can be shared, can be documented properly, and can evolve into automation/CLI/agent workflows as well.

So from my side it is not “UI versus terminal.” That debate is honestly a bit too small. What if we reframe this to: "Can we have one composable, reviewable, reusable representation of API work that serves both the terminal-native people and the wider team without duplicating everything across five tools?"

That is basically the whole bet.

So yeah, I get the skepticism. I have it too. The world does not need another glossy “API client” that turns into a toy the moment you step outside the happy path.

The point of Voiden is precisely to avoid that fate. I am sure you will see how radically different Voiden's take is, if you just give it a spin for a few mins. In a world full of postman clones - we want Voiden to really stand out with a different approach to api tooling. :)

Comment on

Built an API dev tool and got 12k+ installs already, this is what happened since we open sourced.

Reply in thread

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?

Comment on

Voiden - A Markdown based Open Source Alternative to Postman

Reply in thread

Hey :) Voiden is not a rich text editor (non offense to rich text editors). It is executable API docs: requests, docs, and explanations that all live in Markdown… and actually run. (Yes, your docs that do stuff). As far as I know it is the first tool to collapse design, testing, and documentation into one file, one format, one workflow. If you know another tool that does this, I genuinely want to hear about it (definitely not trying to be cocky, just curious :)

Comment on

How to I prove to someone that the U.S. moon landing wasn't staged?

you dont have ti provide anything, the weight of the proof is with the non believer :)

but okay lets go:

beyond all the obvious evidence:

the biggest evidence is around how difficult it would have been to stage it. how many people need to be bribed for eternal silence - this includes suppliers, ex workers, employees, crews, etc...why hasnt anyone admitted the lie in their deathbed?

what I am saying is that it is more difficult to stage this (successfully) than actually do the freakin thing.