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.
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.
All good security measures, for sure, but the blog post you linked doesn’t mention anything about telemetry (ie request data sent to those *.gw.postman.com endpoints). As a user, it would be great to know exactly what data is sent to Postman servers (eg we send resolved query strings, we don’t send headers, etc), as well as to have an easy way to opt out of telemetry altogether.
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.
Hey Abhinav, DX is such a critical component to a successful API, and historically "developer" has meant "human." As agents become important consumers of APIs, what are your thoughts on how DX evolves? Is "agent experience" or "machine experience" different than developer experience?
Hello... I work on the Flows product at Postman. Love this question.
I believe wholly that the definition of a developer is rapidly changing (arguably has already changed). It's clear that it won't mean people who are "classically" trained in software development. I particularly like the view point that we're evolving from developers to conductors (SpecStory did a nice write up on this [1]) where we are more focused on orchestrating Agents.
I also think that APIs will either need to be ready for AI (trusted, solve for authentication, have clear specification, lots of examples) or will be AI dependent to fix them up and put a new layer on top. Discovering the right API to solve the problem is central to the dynamic logic agents introduce to workflows.
I've been building agents for both personal use and for automating internal processes within my team/across the company, and the DX has not felt all the foreign from typical development... an idea, a quick prototype, a tight inner loop for rapid feedback, then a graduation to a deployed asset. While not foreign, doesn't mean there isn't plenty of room for innovation. The DX is where we're really focused today, particularly with Flows.
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...
The original issues were from 2015 & 2017 - Scratchpad was only added to docs in Jun 2021 (before that was an undocumented feature for likely under 2 years I would guess).
Also, on the suitability of Scratchpad as a workaround for this bug, as quoted from person who created the linked issue:
> and no, scratchpad is not a solution to this.
The same sentiment is echoed through many of the more recent closed issues created in Github on this topic.
Either way: my comment above was mainly about dark patterns, which makes the existence of a workaround (not matter how suitable) somewhat moot. Even if this issue gets fixed "properly", the attitude of their devs over this long a period of time has been more than enough to turn me off using their software.
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.
> There are some features that just can't be developed with local storage as the only option
This is disingenuous. Firstly, no-one is asking for this "as the only option"; they're asking for it as an (exclusive) option. Secondly, there are no features being asked for here that can't be developed with local storage as an option - in fact, the default is for local storage to be the only option. In most apps, the approach is to add sync as an extra, not as the required default.
Scratchpad seems a perfect representation of the developers' motivations actually: it's both a demonstration that the feature is possible but deliberately implemented as a non-default side-feature without integration with the app's main workflows, to discourage use. So the devs can give it as a "solution" while continuing to pervasively track the bulk of their userbase.
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.
Are you planning on supporting importing the proto .bin format that stores file descriptors? This is the output of the proto compiler and would make it easier to provide a full transitive closure of deps for people who have complex build phases. You could also make a bazel rule set for exposing `bazel run //service/proto:postman` with default configs.
The nice part of the `.bin` format is you don't need to do anything to support multiple files or cross deps. The build system packages all of the files/messages/services into a single file for you to load.
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.
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. :)
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.