Hacker News new | ask | show | jobs
by a85 1599 days ago
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.

2 comments

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.
Not sure about the .bin format yet but will check with my team. The immediate next step is multi file support.
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.
Thoughts on having native clients for Mac/Windows?
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.