From Postman to bruno: Making the Switch to a Better API Testing Tool

Breaking Up with Postman: Where does it Fall Short#

Postman stores your entire API collection in a single, large JSON file. However, if you choose not to leverage their built-in version control system - which, incidentally, comes with a price tag - then you're left with sharing these JSON files with your team members. Unfortunately, this can create significant maintenance headaches.

And when your colleagues inevitably need to add, delete, or update APIs in the collection, the collaboration feature in Postman is sure to make everything as easy and seamless as possible...said no one ever 🙄

Furthermore, when you switch devices, you may have noticed your collections syncing automatically. Postman accomplishes this by storing your collection on their cloud servers, promising to "improve the overall user experience 🙃" But, as tech-savvy users might discern, this presents a significant security risk since your collections may contain critical API keys or tokens.

API Testing Redefined: The Search for an Open-Source Tool#

I encountered challenges with Postman as it became a bottleneck in my daily workflow for API exploration and testing. I started to find a more effective solution and discovered the following must-have requirements for the ideal tool:

1. It must be open source to align with my preference for transparency and control over the codebase.
2. The tool must enable local storage of collections and API keys, ensuring data privacy and security by not relying on external servers.
3. The storage of collection information must be such that it facilitates seamless collaboration with other team members. Ideally, it should be compatible with git's version control for enhanced team collaboration and versioning.

In addition, the following good-to-have requirements would further augment the tool's effectiveness:

1. The tool should have out-of-the-box support for easy scripting and the importation of external packages to enhance customization and functionality.
2. Capabilities for environment management should be integrated into the tool to facilitate API testing in various environments.

Bruno: The Open Source Solution to API Testing Problems#

Bruno is a sophisticated open source API client, featuring a markup language called Bru, which was crafted as part of the project to manage API information. With its powerful features, it meets all the essential criteria for API exploration and testing. By leveraging the full potential of Bru, it is possible to save and collaborate on collections of API information with ease

bruno represents a significant leap forward in API client technology, with a focus on performance, ease of use, and powerful scripting capabilities.

A Tale of Open Source: How My Search Led to Contribution#

As I started using bruno extensively as my daily API client, I encountered an issue related to pre/post request scripts, which is listed here

Issue Summary#

I wanted to run a pre-request script that would hit a Login API, get the authentication token from the response, and then set the Bearer token in the request header for the current API. As I had to make an external HTTP call, I decided to use node-fetch. However, as soon as I ran the script, I encountered an error:

On any other day, I might have just ignored this issue. But I was quite adamant about not going back to Postman.

Code Break Down - First Attempt#

bruno uses VM2 for scripting under the hood.

The concept of VM in bruno's context is quite simple: the idea is to have an isolated environment where your script is executed. VM2, by default, has multiple options for how you want to set up the environment. One of these options is called sandbox which completely isolates the script and only provides it with some pre-injected packages. This way, you provide the script with only enough resources to perform the required operation. bruno uses the sandbox setting for its VM2 setup.

After delving deep into VM2 and its environment setup, I was quite confident that injecting the required packages should solve my issue. So I made the necessary changes in my local clone and rebuilt the local environment, and Voila! the import issue was resolved.

All should be hunky-dory now, right? Of course not, I am not that fortunate.

After solving the import issue, I wrote the required pre-request script for my use case. The script ran without any errors, but it was not able to set the required headers. Considering it might have been due to the API's bad response time, I wrote another sample script to test my changes:

const axios = require('axios');
response = await axios.get('https://fakestore`API`.com/products?limit=2');
bru.setEnvVar('limit', 1);

For the above script, the value for the env variable limit should have been set to 1 before the current API was executed. But again, it did not happen. The script ran without any errors, but the value of limit did not change in the environment variable.

Second Attempt: Closing the Issue#

Not being able to pinpoint the issue, I went into full debug mode 🧑🏽‍💻. After the debug session, I realized that the script was exiting before the pre-request script finished its execution. As the script was async, this meant that the pre-request script implementation was not waiting for the script to finish its execution and was exiting early. (Others also ran into the same issue)

Digging deeper into VM2, I found that it provides a special type of VM called NodeVM which allows you to require modules in the same way that you would in the regular node's context. bruno uses NodeVM for its internal VM setup.

The issue was with how the script was being executed in NodeVM, and the exact solution can be found in this PR

Final Thoughts#

As a developer, I am always on the lookout for tools that can simplify my workflow and boost my productivity. That's why I made the switch from Postman to bruno. The intuitive and efficient user interface, coupled with the open-source nature of the project, made it an ideal fit for my daily API testing and exploration needs. I was able to streamline my workflow and achieve more in less time.

The experience of contributing to an open-source project like bruno has been nothing short of empowering. It has shown me how much potential there is in the community-driven approach to software development. Being able to contribute my skills and knowledge towards solving a problem and improving a tool that could benefit many developers like me has been a deeply satisfying experience.

Overall, my transition to bruno has not only improved my workflow but also given me the opportunity to be a part of the vibrant open-source community. I am excited to continue to learn and grow alongside this amazing community and contribute to more open-source projects in the future.