dhruv3006

joined 4 weeks ago
[–] dhruv3006@lemmy.world 2 points 1 week ago

yep i got one as well.

[–] dhruv3006@lemmy.world -2 points 1 week ago (1 children)
[–] dhruv3006@lemmy.world 9 points 1 week ago (9 children)

Everyone seems to hate this template.

[–] dhruv3006@lemmy.world 5 points 1 week ago (2 children)

Voiden's core request model is based on composable blocks (for elements like headers and auth) that are reusable across requests for a DRY (Don't Repeat Yourself) approach, unlike Bruno which treats the request as a single, monolithic object that leads to copy-pasting and maintenance burden.

For documentation, Voiden provides living documentation by integrating runnable requests and human explanations side-by-side in the same Markdown file, ensuring it stays in sync with the API, while other tools' documentation is often separate.

From the monetisation side Voiden: Is an open-source community infrastructure project backed by a different main business, reducing the pressure to monetize aggressively. Bruno is as an open-source project that is under pressure to find a viable monetization strategy, which can lead to license shifts or paywalls.

You can read about the comparison here : https://voiden.md/comparison

[–] dhruv3006@lemmy.world 2 points 1 week ago

Its an alternative to Monolithic Requests - Voiden has composable blocks which are an alternative to copy pasting entire request objects. We do not lock in collections in cloud like other api clients like postman and have a file centric and git native approach. Also we offer a unified toolchain - for design, testing, and documentation as an alternative to juggling multiple disconnected apps.

[–] dhruv3006@lemmy.world 5 points 1 week ago (1 children)

That's a pretty good comparison.

The core idea of executable documentation next to your code is exactly what we were aiming for.

The difference is that Voiden is a dedicated, cross-platform app for the modern ecosystem, bringing the power of that file-centric workflow to everyone. We specifically go further by offering resuable composable blocks for requests (closer to functions than monolithic objects), a unified toolchain for design, testing, and documentation, and a clean, Git-native experience for all developers.

 

Voiden is an offline-first, git-native API tool built on Markdown Voiden is an API client we have been building that takes a different approach from most existing tools.

It didn’t start with the idea of “building a better Postman”.

A bit of background. Over time, API tooling has become heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you are offline. On top of that, time wasted on fixing API specs that don’t match the code, docs in separate random tools, tests also separate and an overall governance mess. Not to mention collaboration.

So we asked a simple question: What if an API tool respected how developers already work?

That led to a few core ideas:

  • Offline-first , no accounts, no telemetry
  • Git as the source of truth.
  • Plain text files: specs, tests, and documentation live together in Markdown
  • A programmable interface instead of static forms: requests are composed from reusable blocks (endpoints, headers, auth, params, bodies, etc.) that you can structure the way you want
  • Plugin system for extending functionality rather than bloating the core with new features Some of our core plugins include gRPC,GraphQL,WebSockets,etc…

We have just also updated our docs to welcome community plugins, so teams can extend the tool for their own workflows or integrations. https://docs.voiden.md/docs/plugins/build-a-plugin

We opensourced Voiden because extensibility without openness just shifts the bottleneck. If (API) workflows should be transparent, the tools should be too.

Welcome to try out and share feedback- happy to chat with everyone.

Strong opinions are encouraged. :)

Github : https://github.com/VoidenHQ/voiden

Download here : https://voiden.md/download

 

Voiden is an offline-first, git-native API tool built on Markdown Voiden is an API client we have been building that takes a different approach from most existing tools.

It didn’t start with the idea of “building a better Postman”.

A bit of background. Over time, API tooling has become heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you are offline. On top of that, time wasted on fixing API specs that don’t match the code, docs in separate random tools, tests also separate and an overall governance mess. Not to mention collaboration.

So we asked a simple question: What if an API tool respected how developers already work?

That led to a few core ideas:

  • Offline-first , no accounts, no telemetry
  • Git as the source of truth.
  • Plain text files: specs, tests, and documentation live together in Markdown
  • A programmable interface instead of static forms: requests are composed from reusable blocks (endpoints, headers, auth, params, bodies, etc.) that you can structure the way you want
  • Plugin system for extending functionality rather than bloating the core with new features Some of our core plugins include gRPC,GraphQL,WebSockets,etc…

We have just also updated our docs to welcome community plugins, so teams can extend the tool for their own workflows or integrations. https://docs.voiden.md/docs/plugins/build-a-plugin

We opensourced Voiden because extensibility without openness just shifts the bottleneck. If (API) workflows should be transparent, the tools should be too.

Welcome to try out and share feedback- happy to chat with everyone.

Strong opinions are encouraged. :)

Github : https://github.com/VoidenHQ/voiden

Download here : https://voiden.md/download

[–] dhruv3006@lemmy.world 5 points 1 week ago (1 children)

Well having decent documentation is kind of rare.

[–] dhruv3006@lemmy.world 27 points 1 week ago

Thanks for this.

 
[–] dhruv3006@lemmy.world 3 points 1 week ago

Hey, that’s a fair comparison. .http files are actually one of the closest things conceptually.

The difference is mostly in how far the idea is pushed.

.http files are basically request definitions written in HTTP syntax. They are great for sending requests and keeping them next to your code.

Voiden treats the Markdown file more like an executable API workspace. Requests are composed from reusable blocks (endpoints, auth, headers, params, bodies, etc.), so instead of copying similar requests around you can structure them like small building blocks and reuse them across the file. That becomes useful once an API grows and you start repeating the same pieces everywhere.

Another difference is that the file can mix documentation, explanation, requests, tests, and scripts in the same place and actually run them. The goal is that the file itself becomes the living artifact of the API workflow rather than just a request list. And since everything is still plain text and Git-friendly, you can keep it alongside the codebase the same way you would with .http.

If someone is happy with .http files they probably don’t need Voiden. The idea is more for teams that want the requests, tests, and docs to live together in one executable spec rather than spread across tools.

Do you use .http mostly for quick testing, or do you keep full API workflows in them?

[–] dhruv3006@lemmy.world 2 points 1 week ago

This is actually a great comparison ! Thanks for these words !

 

Voiden is an offline-first, git-native API tool built on Markdown Voiden is an API client we have been building that takes a different approach from most existing tools.

It didn’t start with the idea of “building a better Postman”.

A bit of background. Over time, API tooling has become heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you are offline. On top of that, time wasted on fixing API specs that don't match the code, docs in separate random tools, tests also separate and an overall governance mess. Not to mention collaboration.

So we asked a simple question: What if an API tool respected how developers already work?

That led to a few core ideas:

  • Offline-first , no accounts, no telemetry
  • Git as the source of truth.
  • Plain text files: specs, tests, and documentation live together in Markdown
  • A programmable interface instead of static forms: requests are composed from reusable blocks (endpoints, headers, auth, params, bodies, etc.) that you can structure the way you want
  • Plugin system for extending functionality rather than bloating the core with new features Some of our core plugins include gRPC,GraphQL,WebSockets,etc..

We have just also updated our docs to welcome community plugins, so teams can extend the tool for their own workflows or integrations. https://docs.voiden.md/docs/plugins/build-a-plugin

We opensourced Voiden because extensibility without openness just shifts the bottleneck. If (API) workflows should be transparent, the tools should be too.

Welcome to try out and share feedback- happy to chat with everyone.

Strong opinions are encouraged. :)

Github : https://github.com/VoidenHQ/voiden

Download here : https://voiden.md/download

 
 
 

Voiden is an offline-first, git-native API tool built on Markdown - and it very intentionally didn’t start as “let’s build a better Postman”.

Over time, API tooling became heavyweight: cloud dependencies for local work, forced accounts, proprietary formats, and workflows that break the moment you’re offline. Testing a localhost API shouldn’t need an internet connection.

So we asked a simple question: What if an API tool respected how developers already work?

That led to a few core ideas:

  • Offline-first, no accounts, no telemetry

  • Git as the source of truth

  • Specs, tests, and docs living together in Markdown

We opensourced Voiden because extensibility without openness just shifts the bottleneck.

If workflows should be transparent, the tool should be too.

Github : https://github.com/VoidenHQ/voiden

Download here : https://voiden.md/download

 

Postman teams plan no longer free.

view more: next ›