I like japan, I'd love to visit it someday
Photo by Yu Kato on Unsplash

I am tired of not having enough ram.


Users of computer systems largely have two ways of interacting with a computer system: two “interfaces.” They’re commonly referred to as the GUI (Graphical User Interface) or a CLI (Command Line Interface). The complexity of the final implementation may grant it a different 3-letter acronym; however, they can still be categorized under either of these two terms.

The factors that influence which interface the user will select can be summarized into two: Availability and Convenience.

Convenience: the state of being able to proceed with something without difficulty.

Availability: the quality of being able to be used or obtained.

You could probably get a PhD in just listing out all of the factors, but for the sake of simplicity, those can fall somewhere between the two I’ve listed.

I am a software engineer (I have a piece of paper proving I wasted 4 years); I work with computers a lot and I have developed opinions. I have gone through the ritual hazing of software engineers on StackOverflow, GitHub Issues, HackerNews, IRL, OSS project Matrix chats, Discord servers, and Reddit.

I know how to use

  • linux
  • the terminal
  • curl/wget
  • package managers
  • google
  • <insert your preferred LLM here>

What makes something convenient differs between users, but in all cases, it’s the lack of difficulty that’s important. In my experience, in almost all cases, I have found GUIs, where they’re available, to be far superior to CLIs, where they’re available. GUIs may not be faster than CLIs, but they don’t need to be if your throughput requirements are small. Editing a Word document and exporting it to PDF through a menu is perfectly fine if all you need is to make a dozen PDFs; swap that with several hundred, and now you have a problem.

Using a GUI is very convenient, specifically for tasks that follow a fixed template but require a lot of typing. I can make mistakes typing long strings into the command line; fixing those mistakes may cause me to make more mistakes. I do not like having random bash files littered around for occasions where the only option I had was typing out long strings into the command line. Furthermore, I do not care to learn bash scripting best practices; I find bash inconvenient for tasks that can be accomplished through a GUI. If I need to heavily automate certain things, I will happily use bash (if no other scripting language can do the job); if I need to do low-throughput work, I will prefer using a GUI.

Now that I’ve built my case and glazed GUIs hard, this brings me to my core problem: I AM TIRED OF NOT HAVING ENOUGH RAM. I want to use GUIs where I can; if GUIs start claiming all of my RAM, I cannot get my work done. Electron is a godsend, VSCode is my favorite “Franken-text editor”; the productivity and convenience it provides me greatly overshadow the RAM it consumes. That’s not the case for other GUIs, though, especially developer tools with GUIs. I tried using Postman a total of three times in my life; every time, my laptop would grind to a halt because of its ballooning RAM usage. Postwoman/Insomnia could be better, but it being browser-based, I would never get it to work well with localhost. Postman failed on convenience, Insomnia on availability. Having a desktop icon is underrated.

So, I am done. I want an API client that doesn’t eat a large portion of my RAM. I cannot kill my Rust Analyzer just so I can open Bruno to test a request on the API I just wrote. I cannot rewrite JS Engines to use less RAM; I cannot rewrite Browser Engines to use less RAM; not that rewriting them would actually help reduce RAM usage, but I will rewrite what I can.

I mean no shade towards the great team behind Bruno, their tool is the most light weight electron based GUI API client and is feature rich.

To that end, I want to introduce my step towards fixing this bloat problem: Chashni, a cross-platform API client that is not built on Electron or web views and is currently built using Flutter. Flutter was chosen because it doesn’t sacrifice developer experience, is more inviting to contributions than your wxWidgets C++ codebase, and is well-rounded on desktop.

Goals

  • Memory Efficient: Should stay under 100 MB RAM usage.
  • Accessible Persistence: The persistent file format should be accessible and easy to work with.
  • Portable: Should be a single, portable executable.
  • Straightforward UX: As straightforward to use as possible, with minimal hiding of information behind menus.
  • Previewable Requests: All requests should be as previewable as possible. You should not lose sight of what is being sent, even after sending it.
  • Raw Access: Raw access to data and requests whenever possible.

Have I achieved any of these? Not yet, at least not in its entirety. I need help in adding in the bare minimum feature set so it’s acceptable for use in most major organizations while keeping RAM usage under 100 MB.

Here’s a screenshot of what it looks like right now.

Chashni Screenshot