a85

Yes. The post is misleading and we have more detail on what we do here.

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.

Hello all,

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.

Here’s a workspace (https://www.postman.com/ai-on-postman/postman-ai-agent-build...) if you’d like to explore more - would love to get feedback and thoughts from this community as we continue to build.

Not sure about the .bin format yet but will check with my team. The immediate next step is multi file support.

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.

Many many improvements coming soon to GraphQL tooling in Postman.

You can do a 2-way sync now! https://blog.postman.com/the-reimagined-api-first-workflow-f...

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.

I'll look into it. Thanks for pointing it out!

That is incorrect. You can save requests inside Collections in the Scratchpad and send requests without an account.

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.

Yep. This is a work in progress. Watch out for an announcement in early 2018 about these and other description formats and protocols. :)

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.

https://dcrazed.com/google-chrome-desktop-apps/

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 are always working on making things better. Some videos here: https://www.youtube.com/channel/UCocudCGVb3MmhWQ1aoIgUQw

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.

Thank you for the comment! I think there are ways to represent this better (just with a URL bar for example). Will look into it.

What if the application does have compiled libraries generated from the authored source?

Highest priority item on the list! :)

Time to market means the difference between dying and not dying. I built Postman as a solo developer for 18+ months so have seen the extreme end.

Also, platform parity is not easy to achieve. Even within Javascript environments. Other tools like Fiddler, Charles Proxy etc. for example have NEVER been ported natively to another platform for this reason.

I am pretty surprised how some commenters here are using this argument. Of course, EVERY utility app should NOT be written in Electron.

I have commented on the UI and keyboard shortcuts elsewhere. These are easily doable and I believe libraries to pre-package and solve this exist already.

So native would not cover mobile apps?

We'll investigate if that causes issues with Postman. I haven't faced that problem and I don't think there is a hard limitation on the platform where it can't be optimized. Hardware acceleration is not something that happens continuously - only when things are rendering. More true for games than desktop software perhaps.

It does a lot of things. The table should help https://www.getpostman.com/products (essentially everything with API development)

The table on this page should help: https://www.getpostman.com/products

Reply here: https://news.ycombinator.com/edit?id=13949208