Live data from Hacker News

Postman Now Supports gRPC

blog.postman.com

201–210 of 216 posts

Re: Postman Now Supports gRPC

#201

Earlier quoted context omitted.

You've heard of the Unix philosophy? Small programs that do one thing well. Composeability, so you can combine programs to make new functionality. Rather than build one console app that has 50 features, you build 10 console apps with 10 features each. The complexity of each component stays small while your capabilities as a user grow and grow. This worked originally as the Unix designers were free to organize their c…

> You've heard of the Unix philosophy? Small programs that do one thing well. Composeability, so you can combine programs to make new functionality. That makes sense in terms of CLI utilities where text/files is the standard input/output, or APIs where json/xml/format-of-today is the standard input/output, but how would you do this with GUI tools? I'd love it if there was a solution, but I'm not aware of one. Many su…

An option here might be things like COM and DCOM. Individual, possibly embedded, components and a well defined communications mechanism.

Historically the Amiga was quite nice here with systems using AREXX to communicate (but not embed), and Linux/POSIX has things like DBUS for the same (but less flexibly since there's no middleware between the two for coordinating control between systems, the components need to know about one-another directly - kinda).

Re: Postman Now Supports gRPC

#202
post #185

Left Postman a long time ago after all the stupid decisions. Never looked back. gRPC is a nice addition to Postman though. In contrary to what advocates of gRPC thinks, this kind of development is the key thing to bring gRPC to the wide audience. The lack of test tools for non-developers has been an obvious problem with gRPC. Most people should probably still not use gRPC since it is in most cases useless and causes…

As someone who is about to start a big project with gRPC kind of at the middle of it all would you mind elaborating on the other problems you were alluding to? From the outside and some basic testing it seems great

If you can be flexible about the infrastructure there is no problem with gRPC. Most problems I have seen is that is does not work or perform as well through proxies and load balancers without tweaking.

Re: Postman Now Supports gRPC

#203
post #178
post #59

Earlier quoted context omitted.

Completely agree, I've started making my own open source lightweight version https://github.com/lnenad/probster It's golang + gtk so it uses 30MB of ram. I've made a website https://probster.com with some screenshots. I plan on making a barebones version available for download soon for all platforms, just gotta get around to it because I don't have a lot of experience with delivering desktop apps.

love the idea! i'd be willing to contribute but i'm sort of useless when it comes to go... i do have a suggestion though! lots of open source projects also use open collective [1] to crowd source funds, so if you want to add another payment method for users like me that don't have patreon that might be something to look into. [1] https://opencollective.com/

Thank you, if you want to help me out let me know :). I'll look into it, it's more along the lines of patreon/similar being a way to gauge interest and not a way to live off developing it right now.

Re: Postman Now Supports gRPC

#204
post #68

As I have also been frustrated with the direction Postman has taken, I have a great alternative to suggest, if the only thing you want to do is fire requests on demand easily and do not need automated testing. The VS Code Rest Client extension https://marketplace.visualstudio.com/items?itemName=humao.re... is great for testing and debugging APIs. You create a "my_request.http" file that contains something like POST h…

For you Emacsers that haven't heard of it, the alternative to this https://github.com/pashky/restclient.el

Super straightforward.

Re: Postman Now Supports gRPC

#205
post #147

Earlier quoted context omitted.

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

Not sure what I said that's incorrect? 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 man…

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.

Re: Postman Now Supports gRPC

#206
post #146

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 alrea…

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.

Re: Postman Now Supports gRPC

#207
post #205

Earlier quoted context omitted.

Not sure what I said that's incorrect? 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 man…

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 f…

> 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.

Re: Postman Now Supports gRPC

#208
post #206

Earlier quoted context omitted.

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.

Re: Postman Now Supports gRPC

#209
post #177

Earlier quoted context omitted.

> My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia One of the first things I learned working professionally is that of it’s possible you need to force all engineers to use the same OS. No one will ever agree on one Linux distro. No one wants to develop on Windows (unless you’re developing for Windows). So you should but everyon…

With your reasoning, wouldn't it be work as well to dictate a certain Linux distro?

No one will ever agree on one Linux distro

Re: Postman Now Supports gRPC

#210
post #183

Earlier quoted context omitted.

> My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some team members are also using insomnia One of the first things I learned working professionally is that of it’s possible you need to force all engineers to use the same OS. No one will ever agree on one Linux distro. No one wants to develop on Windows (unless you’re developing for Windows). So you should but everyon…

I am legitimately unsure whether or not your comment is satire of a certain kind of pointy-haired middle managers. If it is, it's very well done.

No I honestly believe it. Never worked anywhere that even has middle managers
Post reply on HN