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

Show HN: Open-source Postman alternative with type safety

recipeui.com

Post reply on HN
Print view View original

41–50 of 94 posts

Re: Show HN: Open-source Postman alternative with type safety

#41

Post by ta8645 »

JrProgrammer wrote: post #40
ta8645 wrote: post #37

After taking a quick look, I still don't know what this is, what Postman is, or who would use either, or for what. No doubt I could spend a bit more time to sort it out, but it would be nice to not have to. Perhaps leaving someone like me to wallow in his ignorance is just fine. But being very clear and concise about what is being offered, without relying on knowledge of another product, might attract more of the uni…

I would argue the offering is actually very clear. A nice demo is included. If you’re not using any REST clients it might be a bit harder to understand but I doubt you’re the intended target group

> I would argue the offering is actually very clear.

What is it?

Re: Show HN: Open-source Postman alternative with type safety

#42

Post by johngladtj »

ta8645 wrote: post #37

After taking a quick look, I still don't know what this is, what Postman is, or who would use either, or for what. No doubt I could spend a bit more time to sort it out, but it would be nice to not have to. Perhaps leaving someone like me to wallow in his ignorance is just fine. But being very clear and concise about what is being offered, without relying on knowledge of another product, might attract more of the uni…

To be fair this is a fairly niche product, and anyone who is in the market for it will know postman.

Ultimately this is a rest client used for troubleshooting, debugging and developing RESTful applications (ie: it's use to connect to websites and APIs.

It honestly looks pretty useful and better than postman so I'll try it out since I work with things that require software like this

Re: Show HN: Open-source Postman alternative with type safety

#43

Post by ishche »

chrisweekly wrote: post #29
Volbohel wrote: post #28

Earlier quoted context omitted.

Looking forward to your feedback when you use it! Currently we validate with mappings from TypeScript to JSONSchema. OpenAPI is definitely a gold standard, but I think JSONSchema is fairly strong as well. We're still considering better typing solutions like ZOD or OpenAPI wrappers, but our focus right now is core feature parity as an API tool. We'll do a better job with written documentation! We forgot that video isn…

> "We forgot that video isn't always a medium that people prefer." I've recently encountered this same apparent strong preference for video at work (where I lead a platform team whose deliverables support dozens of other teams) and while I can accept it (and even embraced it as we create howto videos), it remains very strange to me. When engaging with new tech I always want to see code and well-organized prose, but i…

Also it's still hard to search through videos

Re: Show HN: Open-source Postman alternative with type safety

#44

Post by amne »

This needs a button to import an OpenAPI spec (2.0, 3.0, doesn't matter) and let the user go wild on his own APIs.

I've never thought of an API exploration tool to be a marketplace of ready-baked API collections.

The speed is there, the UI can be improved, the selling point is "wooosh" on me.

Re: Show HN: Open-source Postman alternative with type safety

#45

Post by jabbawookiees »

ta8645 wrote: post #41
JrProgrammer wrote: post #40

Earlier quoted context omitted.

I would argue the offering is actually very clear. A nice demo is included. If you’re not using any REST clients it might be a bit harder to understand but I doubt you’re the intended target group

> I would argue the offering is actually very clear. What is it?

My take: RecipeUI a Postman-like tool that offers convenient type safety and autocomplete on top of what Postman already does.

What is Postman? It's a tool that allows you to configure, save, and replay HTTP requests. It helps developers building backend server APIs, so they don't have to keep fiddling around with their frontend. In many greenfield projects, the frontend doesn't even exist yet and Postman is effectively the only way to easily test what you're working on.

The alternative to postman is writing custom Python/NodeJS/etc programs to send these requests or painfully doing it with curl and bash.

I think it's cool and I'll probably try it the next time I have to work on REST APIs.

Re: Show HN: Open-source Postman alternative with type safety

#46

Post by rgblambda »

nomercy400 wrote: post #39
konaraddi wrote: post #35

Your experience at Robinhood is relatable but I’m not sure I follow how RecipeUI would benefit us more than Postman. Our team has OpenAPI specs but we have a rough time sending requests because each team member has valid requests for some subset of the API surface of a given service (from working on subsets of the service) and there isn’t a common repository for valid requests covering the entire surface area. On top…

Postman is moving more and more from a local tool tp a cloud-based tool under the company's control. Exporting your data from Postman has been made more difficult over the last few releases and now the local scratchpad is about to be removed in favor of using the free account in two weeks time. These actions make me worry that Postman will soon no longer be a free tool or will use my collections and data for their ow…

>and now the local scratchpad is about to be removed in favor of using the free account in two weeks time.

I was under the impression that you could continue using scratchpad so long as you didn't sign in (Which I never felt the need to).

Re: Show HN: Open-source Postman alternative with type safety

#48

Post by myfonj »

Volbohel wrote: post #11
pseudotrash wrote: post #9

It seems postman has put collections behind a paywall so timing for this is great. Does ReceipeUI manage secrets or have some suggestions to deal with this to avoid things leaking into shared cloud storage?

Storing secrets in the cloud has been a top concern for me, which is why we don't do it and one of the main reasons why the code is open sourced. Currently secrets are just stored locally on desktop and web via IndexDB. I'd love to hear people's thoughts on this as well!

One related thing I haven't learned from a glance at the pitch and GH:

Does the desktop app make direct HTTP requests to target resources? Or are they similarly to web-app proxied through recipeui.com?

Plus, is there a way for the web-app to bypass that proxy, when the target resource allows that in CORS (naturally)(or when there is some browser extension that does it on dev's side)?

Re: Show HN: Open-source Postman alternative with type safety

#49

Post by _cenw »

The one piece of Postman that only Hoppscotch (a Postman fork) seems replicate that I definitely want is scripting. Often requests depend upon data from another, and being able to put things into the environment as you run different requests is super useful (even if you just use it for otherwise unsupported auth methods).

Re: Show HN: Open-source Postman alternative with type safety

#50

Post by ShadowBanThis01 »

amne wrote: post #44

This needs a button to import an OpenAPI spec (2.0, 3.0, doesn't matter) and let the user go wild on his own APIs. I've never thought of an API exploration tool to be a marketplace of ready-baked API collections. The speed is there, the UI can be improved, the selling point is "wooosh" on me.

Yes. The OpenAPI ecosystem is in a shockingly shambolic state. I was charged with creating an API for my company's line of network-enabled products, so I defined it in OAS 3.1.

But years after the ratification of this standard, pretty much no tools fully support it, and the code-generation toolchain is a pathetic joke. When I explored it further, I found that this state was well-known in the development community, and that even mentioning an attempt to use the OpenAPI tools was a professional liability... as in nobody who knows WTF they're doing would use this shit.

The best OpenAPI-definition tool I found was Stoplight Studio, which never supported OAS 3.1 and has since been pulled from the "market." They have a Github repo that claims to be the app, but contains none of the source and is only... the documentation? I called them out on it and got only an attitude, and the repo is still up and claiming to be the whole tool. Assholes.

Post reply on HN