Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Postman Now Supports gRPC

blog.postman.com

Post reply on HN
Print view View original

151–160 of 216 posts

Re: Postman Now Supports gRPC

#151

Post by a85 »

atarian wrote: post #149
a85 wrote: 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…

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.

Re: Postman Now Supports gRPC

#153

Post by rattray »

jonfk wrote: post #79

To add another data point, I also moved on from Postman a while ago. Similarly to several commentors here I had found it to have become bloated, slow and buggy imho. In my particular use case, I found the urlencoding when using oauth1 to be pretty buggy. It would sometimes not work on certain headers it generated. My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some t…

Hoppscotch (https://hoppscotch.io/) is another one I've heard good things about.

Personally I like the VSCode REST Client best: https://marketplace.visualstudio.com/items?itemName=humao.re...

Re: Postman Now Supports gRPC

#154

Post by joatmon-snoo »

CSMastermind wrote: post #104
matsemann wrote: post #21

Earlier quoted context omitted.

You can't win. Most features added is because someone wants them. One person's bloat is another person's long sought feature. Like a quote about Microsoft Office: A user only ever uses about 10 percent of the features. The problem is that all users use different 10 percents.

This is solved in food products by differentiation. Someone likes the no pulp orange juice so they buy that and someone else likes the stuff with pulp in it so they buy that. Why not do the same thing with software? Release 10 different flavors of Microsoft Word and let people choose the one they want.

That's called a competing product :)

Re: Postman Now Supports gRPC

#155

Post by lucideer »

a85 wrote: post #147
lucideer wrote: post #132

Earlier quoted context omitted.

For further context: I'm not sure if this has changed but at that time signing in seemed* to be required (there's some discussions in the ticket about confusion in the UI about this so in retrospect UX dark patterns were likely at play). However, while it may have been possible to make ad hoc requests without an account, it didn't seem to be possible to save request collections locally without sign in.

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

Re: Postman Now Supports gRPC

#156

Post by the_arun »

rattray wrote: post #153
jonfk wrote: post #79

To add another data point, I also moved on from Postman a while ago. Similarly to several commentors here I had found it to have become bloated, slow and buggy imho. In my particular use case, I found the urlencoding when using oauth1 to be pretty buggy. It would sometimes not work on certain headers it generated. My team ended up moving to Paw but that has been a bit problematic since it only supports osx, so some t…

Hoppscotch ( https://hoppscotch.io/ ) is another one I've heard good things about. Personally I like the VSCode REST Client best: https://marketplace.visualstudio.com/items?itemName=humao.re...

Do they have desktop client? Hoppscotch seems to be web client. How secure is it to use authtokens for our API endpoints from a website?

Re: Postman Now Supports gRPC

#157

Post by phgn »

oweiler wrote: post #9
nileshtrivedi wrote: post #6

Earlier quoted context omitted.

Try Insomnia or Hoppskotch.

How is Insomnia any different? It's basically an OSS carbon copy of Postman.

That's what I want. A local-only Postman without too many features or configuration overhead. Insomnia is almost perfect for that.

Re: Postman Now Supports gRPC

#158

Post by avel »

halpert wrote: post #136
IshKebab wrote: post #110

Earlier quoted context omitted.

Sounds a lot easier than curl tbh. No need to deal with shell scripts and their insane quoting, plus you get the response straight in your editor with syntax highlighting.

Maybe it’s just me but I’ve never had those issues. Another benefit of curl is that you have an easily searchable history of every command you’ve run. So you can easily find old invocations and rerun them.

This extension also keeps a history of requests.

How complicated are your requests? If I need to test a POST request with a JSON payload longer than a line or two, I'll go and construct my curl command in a text editor anyway, since the shell prompt / readline is not easy to edit. Once you need to start escaping single or double quotes or html payloads in the request, it quickly gets cumbersome. At that point I ditch the shell as a middleman and use the editor to submit the request for me.

Re: Postman Now Supports gRPC

#159

Post by throwaway984393 »

capableweb wrote: post #90
throwaway984393 wrote: post #44

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…

Linux GUI apps use DBUS to communicate between each other. (I'm not a fan of it but it's better than nothing)

Re: Postman Now Supports gRPC

#160

Post by ProtocallDev »

evanmoran wrote: post #145
thcyron wrote: post #67

Earlier quoted context omitted.

It’s definitely on the roadmap. Out of curiosity, do you use client/server streaming or bidirectional streaming?

Server streaming, though I'm not sure how representative we are. We have servers that use streaming for watching for real-time changes. Currently using BloomRPC, if that helps

Grip looks super cool - it's one of the few other clients I've seen that will render structured input fields to make it easier to construct complex messages.

If you have a more urgent need for server-side streaming support, you could also check out Protocall (https://protocall.dev - disclaimer, I'm the author) - it supports all four rpc types (Unary as well as Client/Server/Bidirectional streaming), along with the structured input field rendering and automatic import resolution (via Github repo import).

I wrote it because existing tooling like BloomRPC and gRPCurl were difficult to use for anything more complicated than "Hello, World". I was also looking for tools that would let me send protobuf-encoded requests via HTTP/1.1 rather than gRPC, which didn't seem to exist at the time.

Post reply on HN