Paw is joining Rapid API, Paw for the Web, Windows, and Linux is available | Hacker News Reader

Paw is joining Rapid API, Paw for the Web, Windows, and Linux is available

blog.paw.cloud

123 pointsblacktulip48 comments

I feel like this is a positive for Paw. While I dislike the electronification of everything, I will admit that MacOS is roughly the only desktop operating system with a native UI framework where I prefer applications be written in it; native Windows apps are almost universally horrible, and native Linux (GTK?) apps can be pretty good, but generally aren't (which may be less due to GTK/KDE and more due to the lack of investment on the developer, but the product is the same).

Paw has been a dead project for about three years now. Just as one example, the community has been begging for some kind of structured GraphQL support in the entire timeframe GraphQL went from a "new thing" (when its reasonable to wait and see) to today when its everywhere (when its now insane that an API prototyping client wouldn't have first-class support). They keep it working and going, looks like M1 support came out today as well, but feature-wise its far from a "done" product, yet the developers have treated it like one.

Hopefully this acquisition helps funnel resources into actually building it out rather than letting it languish while still collecting those $50 purchase fees.

> the community has been begging for some kind of structured GraphQL support

They added GraphQL support a few weeks ago: https://blog.paw.cloud/paw-3-2-graphql-macos-big-sur/

I didn't know about the M1 support. Funny enough I looked yesterday randomly when I noticed that Paw was still running under Rosetta. And I saw no word about M1 support yet. I wondered how long it would take. I guess I just needed to wait 12 hours. Glad to see M1 support today.

M1 support coming out is great! I have been fighting with it after starting a new job last week.

The only reason I use Paw instead of the countless alternatives is because it’s not web-based. Sad to see this new development, though thankfully I can still hold onto the last native version.

Edit: was looking at the article on my phone and missed the part where they claim they'll maintain the native version. However I still have concerns they would eventually discontinue it given that Rapid API's main business model is around API marketplaces, gateways and billing and the revenue from selling tooling is likely to be a drop in the bucket in comparison.

> While we'll keep building the native macOS application as a first-class citizen, we're introducing today Paw for the Web, Paw for Windows and Paw for Linux!

Straight from their announcement.

That would be great but I have a hard time believing it'll stay like that. Maintaining two code bases instead of making the "native macOS application" a Electron wrapper around their other code base doesn't seem scalable in the long run.

That's moving the goalposts. The concern was for the native UI to get abandoned, it isn't. It may, or may not. The existence of the cross-platform version is hardly an indicator. If anything, having only the macOS version limited their reach and future expansion.

Not necessarily. The concern was "because it’s not web-based", which could mean that they don't like the web UI or the web based technology stack behind it.

For me a native app has to both look and feel native. An app that looks like a native app (Like an Electron app can) isn't fully native for me because it still runs a web browser under the hood.

I think that's exactly what 'keep[ing] building the native macOS application as a first-class citizen' means.

I dislike Electron as much as the next guy, but that description of what's "native" is IMHO quite arbitrary. Anything using a cross-platform UI toolkit doesn't fit that description, e.g. Qt apps definitely don't look like they are native outside KDE, GTK outside GTK based DEs/WMs, Java apps don't look native anywhere, nor does Tk, etc. while an Electron app that used native-like UI elements could.

I think on macOS the definition of native is most often “Cocoa” and not the absence of web technologies.

It's a spectrum. My hierarchy for Mac apps goes something like: Cocoa > Java > QT >>> Marzipan > Electron.

On old OS's, Carbon would be between Cocoa and Java. And individual apps can vary a bit. But Electron apps generally feel less foreign than QT apps, which at least makes some attempt to use native Mac elements.

^ I'm past the edit window but noticed a bad typo I need to correct—Electron apps feel more foreign than QT apps, not less!

Of course. However, between the close to sweet f*ck-all support we used to get on Linux for some software vs. a decent enough Electron app, I'll still take Electron. But I admittedly do have some RAM to spare.

Could have at least used Java :(

Eh. Outside Jetbrains' IDEs, I don't remember ever using a Java app that didn't feel like clunky as hell.

They're often better on macOS (assuming the developer put in some amount of effort) because Apple helped design the Mac SWING.

Sounds like every announcement of "nothing will change" of any recently acquired company, before the product is shut down and tranformed to something completely different...

Again, this is extrapolation. Until they do it, they didn't.

A dangerous, even if seemlingly cautious, way to approach life and expectations as a user/customer, when there's so much prior experience...

Aka "this time might be different. Let's wait and see...".

I wouldn't put my eggs in that basket.

I would argue the UI is a vast improvement over Postman.

I forked over like 50$ or something for this reason alone.

The development of native version will continue, according to the article.

Same, although an additional reason is that it stores the requests as a plain file that can be yote into version control, instead of an awkward file import / export or (what this version seems to do, as well as Postman) push you to a subscription just to share files.

I'm afraid I'll be sticking to .http files or swagger-ui for now.

>The only reason I use Paw instead of the countless alternatives is because it’s not web-based.

Same.

I spent years at war with others at the company I work with keeping my own copy of paw test APIs up to date while many others used other tools for testing. Paw was just so incredibly killer, notably in the 'make one api call inform another' space. Using Paw always felt like I was almost a developer building my test cases rather than a person using an app. It was pricy, but damn. Good on you people, congrats.

I've used Postman since it was one dude working on it, and have probably created 100+ collections but now I'm about to abandon it since it's getting way too complicated for my use.

It took me almost 10 minutes to just copy an environment yesterday. It was very frustrating to be totally lost in the UI after using Postman for nearly 7 years.

We moved to Paw from Postman specifically because it has less (but higher quality) features. Postman is a mess of a UI, in my opinion. It's so much work to do very trivial things (like copy an environment). We had the feeling that it's hardly a productive solution, but almost makes work in and of itself.

I've bounced around from Postman, to Paw, to Insomnia, and back again for years. I finally dumped a bunch of HTTPie scripts in a folder, made a small runner script in my path, and added autocomplete hooks that just read the filesystem structure.

Now I can run anything from any terminal with history searching. Plus, it's all committed to a repo for anyone else in my org to look at and/or contribute too. I know other tools have collaboration, but can you beat text files + git that you can link to from Slack?

Need to pull an ID out of the third item? Just pipe it to gron and grep. Watch for changes? Put "watch" in front of it. Need to chain three things together? Write a short glue script. It's wonderful.

That sounds really nice. Any chance you could share the runner script and other glue you use?

Right now I'm mostly using restclient.el[1] which I like, but it's not quite as universally sharable as it could be.

[1] https://github.com/pashky/restclient.el

Yeah, it was actually a good day of work to get stood up, mostly around writing a bash script to get and refresh an oauth token (I never use Bash for anything...). I'll see about generalizing and sanitizing it and posting it somewhere.

Well, you have `M-x restclient-copy-curl-command` (`C-c C-u` by default) to share a single command.

There is also Verb mode (org-mode extension) which seems like a nice alternative to restclient.el. Learnt about via Impostman[2] which imports Postman collections to both restclient.el and verb.el

[1] https://github.com/federicotdn/verb

[2] https://github.com/flashcode/impostman/

Interesting. I never really got Postman - always felt like it was worse than Swagger (when available) and more convoluted than curl. I do use SoapUI a bit; mostly for SOAP services, occasionally for REST services.

But I recently found[1] a rust reimplentation of httpie, and some early testing indicates it might be better than curl+jq - bit early to tell.

[1] https://news.ycombinator.com/item?id=26042463

I absolutely love Paw. It rapidly allows me both to test APIs and, more importantly sometimes, create examples for specs. The ability for me to mock up the output one of our in-development APIs in JSON is amazing.

I wish it had some of the scripting of Postman, but that may take away from its simplicity.

I am worried if this will change the user experience of Paw for the Mac. I really appreciated it over Postman but the blo g post makes it sound like it will become a second Postman

Yeah this is always my fear too. I hope it doesn't become the next Postman.

Paw had that feel like it was made by Panic. It was a Mac app that was built with love, funded by a handful of dedicated users who love the app too and want to support the developer. The developer was building it out of passion. They know they aren't going to be on everyone's computers, but the computers they were installed on will have users that love the app above all else. Passion over download numbers.

Now it feels like Paw is going to go the route where they get as many users as possible, across as many Operating Systems. Individual user care is sacrificed in favor of mass adoption. Let's build a web version, lets build a version that your Grandma can use, why not a Kindle version while we are at it? Forget new features, let's build a better marketing site and start making commercials. I hear the superbowl is starting to sell commercials for next year, let's get in on that.

I only recently found out about Paw and was very impressed with its svelte 12MB size and responsive UI. Hope they manage to maintain that experience in the cross-platform versions.

I've recently been using Optic (https://useoptic.com/) which does some cool things in the API tools space, there's potential there to have a CLI UI and they have the history part already but similar to what people are saying here about the web UIs, I don't like theirs much.

I absolutely loved Paw.

Before GraphQL, Paw was a necessary and often daily part of my FE team’s toolset. Since GraphQL and tools like Graphiql, I haven’t found myself using Paw. Its killer-feature for me was chaining together long sequences of REST requests that dynamically depended upon one another’s results.

I’m curious if others are using Paw in a GraphQL context?

3.2 added some rudimentary GraphQL support but it’s not comparable to Insomnia so I went back to that

Just loading it now and there’s an update (3.2.1) - it mentions some GQL documentation improvements in the change log but unsure if it’s tangibly better

The GQL features have nothing on GraphiQL+Explorer. Depending on how much you value the native UI, dynamic features etc it may still be worth it. It is for me, but I use it alongside GraphiQL all the time.

I use Paw for GraphQL every day, including variables, schemas, and docs. The autocomplete works well enough, and when plugging into the larger Paw project things work very well.

My only big gripe is I can't write JSON to modify variables, I have to interact with a JSON tree UI and add items one at a time.

Also a long time Paw user. By and large a great Mac app.

I did have a dalliance with Pycharm’s Testing Restful Web Services tool two months ago.

It was released in July of last year and as I’ve moved more and more functions of building into the IDE, API testing seemed like a great fit for inclusion.

What I found was the product wasn’t quite ready, and reported something to JB that was accepted as a bug in the tool. That bug still sits unplanned, and I started both next projects in Paw.

One thing I was able to do was build a macro that allowed me to hit a hotkey while in pycharm that would run the currently selected Paw request.

It would then tab back to pycharm. Worked pretty well, but really would be cool if Paw just added a global hot key.

I hope the product gets more attention, or if anything it inspires others to build native MacOs tools.

Is it just me or is there no way to import prior `.paw` files to the new UI? I've looked in both the web and Linux version (both the same) to no avail.

Has anyone used the parent company's product (RapidAPI)? It seems like a proxy in front of APIs, most of which aren't actually integrated and need to be configured separately. I feel like I am missing something.

I hope Paw doesn't end up as poorly designed as this.

Not to be confused with https://en.m.wikipedia.org/wiki/Physics_Analysis_Workstation

Isn't Rapid API owned by Kong, which also owns Insomnia?

Rapid API bought Kong's marketplace and Kong now focuses on their API management product. They are separate companies.

Reply on news.ycombinator.com