General feedback after using Voiden two weeks for work

[czim]

In follow-up to a Lemmy interaction, here's a quick list of feedback points that I collected:

This is using version 1.3.1 on MacOS Tahoe 26.3. I use it as a backend developer working on API-based sync processes for RESTful JSON, XML and some GraphQL.

• For me, a big issue is that I cannot seem to have multiple Voiden windows open at the same time. I often have to work on different projects, or different APIs for the same project, and I have to switch often. I like the switching mechanic, but I really just want to CMD+backtick and switch between different requests from entirely different projects, ideally. Having to completely switch projects and re-set environments is tedious.

• The response pane is a little too restrictive for serious usage. I usually copy/paste everything from it to an external text editor, just to be able to review/browse anything but the simplest responses.

  • It would be way better if the pane had a visible/usable scroll bar.
  • It would help if the pane could be vertically resized.
  • It would be very useful to be able to search the response content with a simple term search.

• A very minor point: The request data in the side bar has everything except the body data that was sent. This is very useful when body content is variable (such as when scripting, using variables etc.).

• It would streamline editing if it were allowed to place a cursor between two blocks (either by keyboard and/or by mouse), so you can easily insert a block or text between two blocks without. (When clicking a block’s hamburger menu, you can use CMD+shift+<up/down>, but only after having that menu open.

  • A short-cut key to 'add block above the one above (again) where the cursor is' might also help (however clunky to name).

• It would be nice to have some way to have multiple request setups in a single .void file. Perhaps allow this when they are split by a divider ---, or by top-level headers?

• This would also make it natural and nice to be able to chain those events in a single action. 'Run all requests' would be a great way to test a flow or feature in a single, intuitive markdown page.

• Not really bothered by this, but Voiden seems unable to handle very large responses, such as a 120 Mb XML file. Even with a 2 minute timeout, it 'just stops' after 15 seconds or so, not showing any response data, not even an error. This does not really affect my work, but it does mean I do some stuff directly in curl or another tool in some cases.

I hope it's okay to provide my feedback this way. I really don't want to use Discord if I can avoid it.

[nikolasdimitr]

thanks @czim for your points. I hope that you have been enjoying Voiden these two weeks.

yes @czim you can definitely avoid it - sharing your feedback here and in this form is great. This is actually the best way and how we prefer. Discord is great for other things and for real talks - you are welcome to join our office hours tomorrow where we talk about that an other feedback and ideas in real time.

we will create separate tickets perhaps for some of these items you shared - so that we can update on the progress of the separate items.

[kaluvuri]

100% appreciate the feedback (in any form) @czim !
I agree with you on almost every point. And in fact I, as a daily user of Voiden, have been struggling with some of them myself.

Few clarification points:

Multiple Windows

For me, a big issue is that I cannot seem to have multiple Voiden windows open at the same time. I often have to work on different projects, or different APIs for the same project, and I have to switch often. I like the switching mechanic, but I really just want to CMD+backtick and switch between different requests from entirely different projects, ideally. Having to completely switch projects and re-set environments is tedious.

Voiden does have the multi window support -

Is that what you are mentioning here - or is this a bit different?

Mutliple requests:

It would be nice to have some way to have multiple request setups in a single .void file. Perhaps allow this when they are split by a divider ---, or by top-level headers?

This is a big design decision - that we have toyed with, technically its just easy to implement it the way Voiden has been built (and at one point in its history - it did have multiple requests per doc) - but the challenge has always been UX - we already allow importing and reusing blocks, overriding blocks with-in a single document - all which are sort of new UX in the api tooling and when we have multiple requests per doc - we somehow have to let the user "pick" the request to send or infer it based on the cursor (which request) block they are in and so on.

But now that we have the settings screen - maybe we can actually put this behind a toggle this option to enable "multiple requests per doc" and reuse it. So I think its time we take this up.

With the rest - I agree - the big changes will be coming next week to the response panel view (the find option in the response panel is disabled due to a regression, we will fix that as well).

[czim]

Multiple Windows

Got it, my bad. I completely missed that option and just incorrectly expected it to default to opening projects in new windows (must be me being used to Jetbrains stuff). Scratch that point off my list, this works just fine.

Multiple requests

If it were up to me, this wouldn't be high on the list, but a toggle sounds great.

Edit: alternative idea: the ability to import an entire file (= request) in another file and collect and chain them in that way, would serve the same purpose. One could then make folders of flow requests and one top-level file that would have them in a chained setup, f.i. Would work well (even) when there'd be no way of mixing blocks and file imports. But just spitballing.

New

• One very minor thing I forgot: memory for window size/position. When opening new Voiden windows, it would be nice to have it open in the same size and position as the last known window's. Ideally between quit & restart as well. (Again, very minor -- in my case it would save me one key combo to click per window.)

• I like and use the pre & post request blocks often. The most common use-case I have for it is to perform an authorization and use the retrieved (bearer) token in the other requests. One thing I did like about Postman is that it would update/change environment variable values (ephemerically) with scripts -- the runtime variables in Voiden are cool, but having some option to override/update environment variables as well, would make it even better.

Edit: another one:

• Working with more than a few request tabs open is a bit annoying.
  • Navigating to tabs as they drop out of view is cumbersome. Is there some way to list all open tabs that I'm unaware of?
  • When the request execution/response panel is open, this reduces the room available for request tabs. If the tabs could flow above that panel, there'd be more room and it would not depend on how wide you'd prefer the panel to be.
  • When the file names grow larger, the tab width increases. This could do with some clever tab-width compression approach, so that you only see the full tab label when hovering, f.i.
  • An option in the settings to allow tabs to flow to a new line, so you can have multiple rows of tabs, would also be great.

Edit 2: small one:

• When duplicating a file, it would make more sense to focus / switch to the new duplicate. Expected flow is to start editing the duplicate. For me personally, it would be ideal if the rename action would immediately start on the duplicate (because everyone will want to change the " copy" default to something else anyway).

The positive

• I love the idea behind this. A great showcase of how tools by-and-for developers can change the game. The markdown block content is a little clunky to write in other editors, by hand, but every other advantage of this approach stands out immediately. I especially love the anti-enshittification mindset and the point of using git instead of home-spinning collaboration.
• The Postman import works fine and is a big time-saver. I'm pretty specific about how I want things, so the more I import, the more I have to tweak and refactor to reusable blocks and so on, but it's easy to automate due to it all being markdown, so that's pretty great. We can even make our own company-wide import (cleanup) process to make migration easier, if we want.
• Speaking of: I am recommending Voiden to my colleagues where I can. Some of them are deeper into GraphQL projects than I am, so that might result in feedback, which I'll keep an ear out for.
• I also appreciate your enthusiasm and eagerness. The cynic in me wonders a bit where it's coming from and what's in it for you guys -- worrying about the 'catch' of this. I guess you could take that as a compliment?

And for the bread-and-butter of this, just performing requests, no complaints. It just works -- the good kind of 'boring'.

[kaluvuri]

@czim Thanks a lot for taking the time to write all of this up. This is exactly the kind of feedback that is useful for us: detailed, grounded in actual usage (and real scenarios), and coming from someone clearly trying to make the tool work seriously in their day-to-day flow. Please do keep it coming.

With the new beta release, you should find that quite a few of these points have already been addressed: 1.4.1-beta.1.

I tried to tackle a number of the response panel pain points you mentioned in particular — resizable panes, search, and remembering response panel widths.

On top of that, we introduced Voiden Stitch (the name will make more sense over time :D), which is roughly our equivalent of a collection runner in Postman.

But the biggest change is probably the ability to have multiple requests in a single .void file. That one, especially, was something I had been on the fence about for a long time. So in a very real sense, your feedback helped push that over the line.

I’m sending over a Loom link so you can see the changes in action. Apologies that I could not record voice on it — things were a bit noisy around me when I recorded it.

https://www.loom.com/share/95405afea79d49be9078c6ca0a9dfbb3

A number of the smaller improvements you mentioned also make a lot of sense, and in general I agree with most of them. Those will be picked up and addressed in upcoming releases.

The only one I’m still a bit cautious about is directly overriding environment variables. Not because the use case is not valid — it absolutely is — but because I want to think carefully about the model there so it does not become confusing or unpredictable over time. I’ll create a separate ticket for that, tag you there, and share the approach I have in mind, along with the concerns I’m trying to work through.

On the broader question of motivation — and the “what’s the catch?” part — honestly, it is pretty straightforward.

There is no grand hidden twist. We were frustrated with the state of API tooling, built something for ourselves, showed it to users, and realized others wanted it too. Since our actual business is ApyHub, the API marketplace, and not Voiden, we had the room to open this up properly instead of turning it into another lock-in play. So yes, part of it is principled, but part of it is also very practical.

The open-source part came later, once we were confident we could support it seriously and not just throw it over the wall with good intentions. The models I look at here are things like VS Code or Backstage. They work in part because Microsoft or Spotify do not need those tools to behave like little toll booths. That tends to produce better tools, because the incentives are less distorted.

That is roughly where Voiden sits for us. ApyHub is our revenue engine. Voiden came out of our own pain, and opening it up was a deliberate choice once we knew we could maintain it properly. So yes, there is some idealism in that, but also a very practical belief that this space has been stagnant for too long. Postman’s influence is visible across almost every tool in the category, and we felt the space needed a proper nudge. We’re giving that our best shot.

If we end up winning over a big part of the user base (I sincerely hope so) - great! If we push everyone else to innovate and improve the developer experience, I’d still count that as a win! :D

[czim]

Thanks for the long response, good read!

I've one more that would make migrating existing collections smoother:

A short-cut key to rename a file in Voiden. On MacOS that normally would be [enter] (and then [space] would open the file instead), but [F2] would probably be a better platform-independent choice.

Adding imported blocks works pretty smoothly when I'm doing a large import. I run the file generate. Then I make a shared blocks file and then I go through all the generated files, rename them and add/replace blocks with imports from the shared blocks file. Once I got used to it, the [@] -> pick file, [space] -> pick block -> [enter] flow can work pretty fast.

Finally, is there an overview page or block that we can use to see a list of all runtime variables that were set so far?

[kaluvuri]

Shortcut key:
yes we can add that in. Maybe OS specific ones - just for users not to continue with their muscle memory.

Imported Blocks
Adding imported blocks works pretty smoothly when I'm doing a large import. I run the file generate. Then I make a shared blocks file and then I go through all the generated files, rename them and add/replace blocks with imports from the shared blocks file. Once I got used to it, the [@] -> pick file, [space] -> pick block -> [enter] flow can work pretty fast.

I am thinking of a smart import functionality that can auto detect similar ones and organize this. And maybe not just at the import time but even later you can do this. Like in IntelliJ you have "Find Method Duplicate and replace with calls". Something like that.

What do you think of that?

Overview page for runtime variables:

• Yes adding that view soon.

[czim]

W.r. to the smart import functionality: sounds like a great nice-to-have feature. Though, now that I think about it, perhaps overkill? Perhaps you could (let users) rely on using LLMs for such reorganizations.

Unrelated: I talked to a colleague yesterday who works on GraphQL projects mainly, and they were not able to get Voiden working for them. It tended to 'undo' / forget changes they made to queries, when I was 'looking over their shoulder'. They were changing the input for a logging and Voiden kept resetting the input to null and wouldn't allow him to set an object -- even though the schema discovery seemed to work just fine. I've asked them to keep notes on such issues and post them here (or let me post them here), so more details to follow.

[nikolasdimitr]

thanks for the heads up @czim

We have made a few changes to Graph QL and they are on beta. Can you advise your colleague to update to the latest beta?

We are plannig to move these changes to a stable release next week.

[nikolasdimitr]

@czim quick follow up - the multiple requests per doc are now pushed on stable release. You can also 'Run all requests' or one by one separately in the same page. Did you have the chance to try? https://docs.voiden.md/docs/core-features-section/multiple-endpoints/multiple-endpoints-overview

also, any news on your colleagues and their issues with Graph QL?

[czim]

I have not been able to try the multi-per-page feature yet, I'll add it to my todo list for when work lets up a bit.

No feedback from my colleagues yet, but I do have some initial comments of my own:

• Color/highlight (red/green) for variables in GraphQL block endpoint inputs does not seem to work. The variable replace works fine, but no 'confirmation' that the variable exists.

• GraphQL requests, including the 'connect' for the schema call, do not seem to send the Authentication header. This happens when using an authentication block, a header block with the header explicitly in it and also when using the import block approach. Putting the blocks before or after the graphql block makes no difference.
  Other custom headers are ignored as well.

For testing I just disabled authorization locally, and the graphql calls do work.

• When using the 'eye' explorer approach, selecting stuff works fine. It would be really helpful to have 'select all' at each level (or at least the top level(s)), for cases where there are quite a few properties to be selected.

• I have not been able to reproduce the issue my colleague had, where his manual edits of queries were 'undone' immediately, but I'll play around to see if I can reproduce that.

(This is on version 1.4.4.)

---

One unrelated minor annoyance I have is with multi-window usage. Whenever I open Voiden, it opens about 4 windows for different projects I once had open. It does not open the windows/projects I had open the last time I quit Voiden, just the same 'older' project windows every time.
Personally, I'd rather either have no multi-windows auto-open at all (just the one 'empty' window); or the ones that were open the last time Voiden was quit. Having the windows open at the same size/position they were before would be a bonus, but not important.

---

Plus another unrelated, pretty random bug that I ran into and cannot reproduce, but I'll mention it anyway:
I created a new folder, with some env files and a .gitignore from another Voiden project. I opened that as a folder in a new Voiden window. Then I started editing both the .env-public.yaml and .env-private.yaml files. For some reason, Voiden would keep overwriting my .env-private.yaml with the contents of the .env-public.yaml. I 'fixed' it by closing both files in Voiden and editing them in a different editor. When closing out of Voiden entirely and opening up the project again, the issue was gone. (But for now I feel I have to 'save' my private env data in another private spot just to be sure I don't randomly lose it. 😅 )

[dp1620]

Hey @czim ,

Thanks for reporting these issues ! We will verify the issues and work on the fixes. We are planning to include them in a patch release on Monday.

[davinder-sudo]

Hey @czim
Thank you for sharing your feedback and detailed observations.

We are currently prioritizing and addressing other reported bugs and improvements. Regarding the multi-window behavior:

When multiple windows are open, the correct way to close a window is via the hamburger menu → File → Close Window. If the application is closed directly, it preserves the current session state. As a result, when you reopen Voiden, it restores the previously open windows.

We understand your concern and preference around window restoration behavior, and we’ll take this into consideration for future improvements.

[davinder-sudo]

Hi @czim,

We’ve fixed the issues you highlighted and created a separate ticket to track the remaining bugs:
#318

We’re actively working on your other feedback as well, and we’ve kept this ticket open to track that progress.
The new version 1.5.0 is out. please give it a try and share your feedback.