Postman allows for turning off history, keeping variables local, setting up a local vault all in the free product and in more advanced plans, there are secret scanning capabilities for IT and security teams.
These issues are not unique to Postman and apply to all cloud products like GitHub as an instance. Products that are “offline” just shift the burden to the user.
Postman founder here. I did not time this with an AWS outage of this magnitude but I posted about filesystem, git, and offline support coming to Postman last week: https://x.com/a85/status/1978979495836356819?s=46
Postman has a lot of capabilities now that require the cloud but there is still an offline client built in just for requests.
Building sign-in and cloud features were not due to a VC-led conspiracy. A large number of companies depend on APIs (like AWS) and have thousands of services and APIs. Customers need to manage them and wanted us to build it.
Hi, I’m Abhinav, one of the founders and CEO of Postman. We’ve just launched a suite of tools to simplify working with APIs and LLMs in agent workflows, leveraging our network of 100K APIs to enhance and scale agent capabilities.
Scratchpad was specifically added as a feature to clearly allow people to use it Postman in an offline mode because otherwise people were confused about the distinction between an offline/online mode (Why is my content not showing up on Postman's web version for example). There are some features that just can't be developed with local storage as the only option.
An exceptionally large majority of users that give us feedback are pretty happy with the collaborative online features that we provide through Workspaces.
Unfortunately, a small but vocal minority is insistent that all those things be not developed because they have built their own workarounds through patterns from decades ago (CLIs, editors, repositories). I just don't agree with the sentiment that progress towards making lives easier for others should be stopped for a narrow viewpoint to be met. I also understand that it will lead to alternatives but so far almost everything that I have seen in the market has been a clone of our feature set - open source or closed source. I am happy to see people compete with new ideas.
We introduced two-way sync with GitHub, GitLab, BitBucket etc recently so you can keep your Postman collections inside version control while being able to work with them inside Workspaces. Details here: https://blog.postman.com/the-reimagined-api-first-workflow-f...
Not as of now unfortunately. It is very hard to maintain multiple codebases that basically do the same thing. It is doubly hard for software that is supposed to validate other software because as solving every bug becomes a nightmare. We are focused on bringing a near-native experience on Windows and macOS this year though with better keybindings and UI layer integrations with the OS.
That said, we are looking into iOS and mobile devices right now - a smaller problem set before we look into native clients.
Postman founder here. Thank you HN community for highlighting this feature. We have been seeing gRPC usage exploding especially in microservices driven architectures and we are looking forward to the feedback we get on the feature.
A few other observations on comments that I read through:
1. Postman leans towards adding UI affordances instead of hiding them. This can irritate experienced developers at times who already know the complexities of HTTP or other protocols but that is really how new developers find their way around. So while it is attractive to have 1000 options hidden behind a command line interface, nobody uses 995 of those features. We are getting better at building experiences for both experienced and new developers. Also, I don’t believe reading man pages of git or curl is a better experience.
2. Performance is a huge area for improvement. More to come in subsequent releases this year.
3. Our roadmap is community driven: https://github.com/postmanlabs/postman-app-support/issues. Raising more investment helps us do more. We have built a business model around doing the maximum for every developer on the planet while also providing value to companies so we can charge for it and continue development. I find it fair that companies spend hundreds of millions of dollars on salaries can pay some money for improving their productivity by spending in developer tools.
4. API Development is a huge and growing area and developers are spending more and more time working with APIs rather than their IDEs. API Design, documentation, and testing are areas that a large number of developers tell us they wish they had better tooling for. Most of their time is spend pointlessly in trying to figure out how an API works (in some cases whether an API even exists). We decided to take Postman in those areas even though paradoxically it might lead to “less” Postman usage. (The faster people figure out an API the fewer number of calls they have to send)
5. Finally, it is good to see here a call for fewer features which we insist internally as well. Unfortunately at some point some part of the community is upset that we are NOT adding features (just see the gRPC thread on our issue tracker!). We don’t see issues to remove features as much as we have requests to fulfill. We do remove features consciously but it is a hard problem, so we default to adding them slowly.
Sorry about that issue. We have been working on the migration from the Chrome app to the Electron based app for a while. The final set of changes in the runtime went through in v5.4 (collection level auth, variables, scripts etc.). Changes closer to the network layer will start trickling in through soon. It seems like a long time for a bug, but we have been releasing version updates almost every 2-3 weeks. :)
This is where I believe we'd differ. Postman already had a "desktop" app in the sense that Chrome apps also existed as desktop apps and when we ask users to switch, they wouldn't.
For most users, desktop apps = things that run on the desktop.
Agreed. However, perceptions change as technology improves and overall the arc of software tools has been towards higher level abstractions unless absolutely required to go deeper.
Thanks for the comment! If you are on Postman Pro you can export to Github directly. There is versioning built-in Pro too. That said, we have improved the format a lot over the years to support diffing just with Git.
We don't need to change the chromium source. Everything is not sitting on top of Chromium. I haven't tried this just yet but node-pre-gyp allows packaging C++ too. https://github.com/mapbox/node-pre-gyp
Hmm. If you are on Postman, I'd love to get your help in debugging this. Performance issues that I have seen exist at massive scale for us - ~10K requests or hundreds of collections. Of course, working on optimizing for all of these cases.
https://blog.postman.com/engineering/postman-free-is-secure-...
Postman allows for turning off history, keeping variables local, setting up a local vault all in the free product and in more advanced plans, there are secret scanning capabilities for IT and security teams.
https://blog.postman.com/choose-the-right-postman-plan-for-y...
These issues are not unique to Postman and apply to all cloud products like GitHub as an instance. Products that are “offline” just shift the burden to the user.