You’re a Software Engineer at Postman. What would you say … you do here?
I primarily work on the backend side of things at Postman. I’m working on improving the mock server feature to support the various use cases for our users.
Mocks can now be used to host your static website or provide an executable API specification to anyone building applications for you, even outside your organization.
I also contribute to the Postman collaboration service (sync server) which is responsible for anything that has to do with collections and things you use in the app that sync in real time across different members of your Postman team.
You’ve worked at Postman for 7 months. How did you get started working at Postman?
I have been using Postman for API testing since Postman first started. I purchased the first ever add-on in 2013. I knew Postman’s CEO Abhinav Asthana from my college days and used to follow the product closely. I wanted to contribute to the open source parts of the project, but I never really got around to doing it.
Earlier this year, I was looking for an opportunity at Postman. I met Postman’s CTO Ankit Sobti, and after a couple of interesting interviews and product roadmap discussions, I started working at Postman.
What tech do you get to work with?
Most of the backend stack is written in Sails.js – a Node.js MVC framework with built-in support for WebSockets, with MySQL as the database. I mostly write code around the backend stack using libraries like Lodash and Async.
A decent amount of my time also goes into writing comprehensive tests using Mocha, expect.js, and writing mock stubs for all the microservices that we talk to.
I also end up writing a bunch of code that consumes the Postman collection SDK and writes Postman collections to execute code using the built-in Postman APIs.
What’s something cool you’ve worked on recently?
Mock servers is one of them. It is a simple yet powerful feature which can enable a lot of different kinds of workflows.
I also added a couple of new integrations to Postman. The cool thing about writing an integration is that it is just another executable Postman collection triggered via a webhook.
I also wrote some collections that do meta-operations on our collections. One is a collection that backs up our set of collections that do integrations to Bitbucket. Another one just cleans up all the unnecessary test collections that I end up creating during integration test failures and such.
What is one thing everyone should know about the Postman app?
Postman mock servers have some very versatile use cases. At Postman, in addition to using a mock as the static content server for the Postman website, we also use mocks internally to interface between different microservices during test and development.
Mock servers can be used to build a serverless workflow. For example, you could use a mock to render a page that captures input from a user, update a Postman environment, and trigger a Postman monitor run using the Postman API. The Postman monitor then executes your collection with the updated environment, doing whatever it wants with the data, and then triggers a flow into your system using Postman integrations or any service or datastore exposed via HTTP.
Also, Postman collections have their own version control. Postman also supports version controlling your collections via GitHub, Bitbucket, GitLab, and all the rest.
Any other DevTools that you love using, besides Postman of course?
I like zsh on the command line. The autocorrect functionality along with the ability to filter through previously typed commands makes the command line as simple as searching on Google.
What is something we don’t know about you?
I do weekend breakfast bicycle rides coupled with visits to some of the nicer lakes in Bangalore. Sometimes, I also do late night rides. I once did a Dark Knight cycle ride around the ring road that circles the city, wearing the Batman cape.
Want to join the team at Postman? We’re hiring!