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

81–90 of 216 posts

Re: Postman Now Supports gRPC

#81

Post by cyral »

adam_arthur wrote: post #73
paozac wrote: post #5

I used to like Postman, when it was a simple browser extension. I basically used it as a curl gui. Now > Postman is an API platform for building and using APIs. Postman simplifies each step of the API lifecycle and streamlines collaboration so you can create better APIs—faster. I guess I’m no longer their target user. Back to curl/httpie.

The UX has gotten noticeably worse for me. Maybe I'm using it wrong, but now you have to setup a project and name things before you can actually start issuing requests. And I found the whole experience a bit confusing in terms of user flow

It really needs some love in the UX department. There are so many icons and toolbars it is hard to understand where to find things or why they are placed where they are.

Re: Postman Now Supports gRPC

#82

Post by dec0dedab0de »

I see people complaining about what postman has become, but I never really saw the need for it to begin with.

When I'm exploring a new API I just do it in jupyter with python/requests. This way, when I figure out how to do what I want I already have some working code. I can see how this workflow would be a pain in a static language, but for dynamic languages I don't understand why more people don't do it this way.

Re: Postman Now Supports gRPC

#83

Post by capableweb »

skrebbel wrote: post #55
BiteCode_dev wrote: post #40

Earlier quoted context omitted.

Incidently, httpie is getting a GUI: https://github.com/httpie/desktop

And VC funding!

Oh, that's really unfortunate, I really like httpie. I wonder how long time it'll take for them to end up trying to extract as much value from each user as possible...

Re: Postman Now Supports gRPC

#84

Post by rplnt »

dec0dedab0de wrote: post #82

I see people complaining about what postman has become, but I never really saw the need for it to begin with. When I'm exploring a new API I just do it in jupyter with python/requests. This way, when I figure out how to do what I want I already have some working code. I can see how this workflow would be a pain in a static language, but for dynamic languages I don't understand why more people don't do it this way.

To be fair, you can export python code from Postman as well.

And it allows you to load swagger/openapi spec which makes the exploration phase rather trivial.

disclaimer: I also hate using Postman because it's too big, complex, slow

Re: Postman Now Supports gRPC

#85

Post by halpert »

avel wrote: 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…

Doesn’t curl do this just as easily?

Re: Postman Now Supports gRPC

#86

Post by capableweb »

lukevp wrote: post #39
jim180 wrote: post #33

Earlier quoted context omitted.

No, we are not gonna kill native macOS app![0] [0] I'm lead developer for macOS app :)

It seems unrealistic long term for any company to maintain one native app and an electron app across other platforms. Spotify did this for a while, but they eventually forced everyone onto the electron app. Something to keep in mind.

> It seems unrealistic long term for any company to maintain one native app and an electron app across other platforms

Not sure if it's more or less unrealistic to have one native app per platform.

> Spotify did this for a while, but they eventually forced everyone onto the electron app

I don't think (but someone correct me if I'm wrong please) Spotify has ever been a Electron app. If I recall correctly they are indeed embedding Chromium but they are doing their own custom binding (possibly via CEF), not via Electron.

Re: Postman Now Supports gRPC

#87

Post by jkbr »

piokoch wrote: post #51
lovedaddy wrote: post #10

Earlier quoted context omitted.

The latest updates from httpie have an insomnia type rest client workspace thing. https://httpie.io/product

This is some invite only software, am I missing something? I couldn't use it right away, I was asked to join waitlist.

HTTPie for Web & Desktop is in private beta. We’re shipping updates weekly and inviting people from the waitlist every day. As soon as we’ve tackled the few remaining things on our roadmap and polished some rough edges, it’ll become publicly available.

Re: Postman Now Supports gRPC

#89

Post by avel »

avel wrote: 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…

Someone posted https://hurl.dev/ below. It looks like a command-line alternative to this, with a similar format, and support for assertions.

Re: Postman Now Supports gRPC

#90

Post by capableweb »

throwaway984393 wrote: post #44
adhoc_slime wrote: post #14

I have a meta question to ask, in threads like these where big products announce new features or big funding I always see commentors lamenting bloated software or it having too many features, not doing the one simple thing you want it to do, etc. To me it seems the only trajectory of developers building products is to add new features, its how we justify keeping ourselves around most of the time. So what my question…

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 suites of software use a standard format for things (like .obj/.fbx for graphic object/animation, or .wav for music production), but there is usually not a pipeline as in "pipe this output from this software into that input to that software" like we do with CLI utilities, and if there is, that pipeline is not standarized nor open for extension. Will it ever be possible? I hope so, but I don't see how it can be right now.

Post reply on HN