mittsh

Paw & RapidAPI | Building world-class tools for API developers | Remote in Europe (GMT +00 to +03)

Positions: macOS Software Engineer (Swift & Objective-C) | Frontend Software Engineer (React)

At Paw, our goal is to build the best possible productivity tools for developers, and in particular, for building and designing APIs (REST & GraphQL). Paw was launched as a Mac-only application and has recently become available on the Web, Windows and Linux. It allows team collaboration via a cloud-based syncing backend. We’re proud to have Airbnb, Apple, Mailchimp, MessageBird, and many other leading tech companies among our most active customers.

- Our product: https://paw.cloud/ - We're part of RapidAPI: https://www.crunchbase.com/organization/rapidapi - Our open positions: https://blog.paw.cloud/join-us/ - Email us: [email protected] (CV or LinkedIn URL please)

Paw founder here. I'm very sorry to hear this. If you don't mind, I'd love to know more details on what's happening. The logs available in Paw menu > "Get Debug Info…" are very helpful. If you don't mind sending these details to [email protected], we'd be very grateful! Thx!

Yep, I've got exactly the same yesterday until Uber asked me to grant "Always" location tracking. Not only I dislike the forceful location grant but they had a bug that didn't prompt me for it until I rebooted the app twice :)

They released the first mass market all-in-one personal computer with mouse input + pixel based text rendering, multiple fonts & cursive. They pushed for USB-A standard 19 years ago. They killed parallel & serial ports. They started the trend of making beautiful devices that don't feel like minified mainframes. They made UNIX truly mass market. They made the first music player that could handle more than 8 songs. They revolutionized smartphones + introduced touch based keyboards. They created WebKit.

They also advertised. And I love most of their ads (at least those during Steve Jobs' time).

AppKit + Foundation is always NS, UIKit always UI. But who cares now that we have Swift ;)

Xcode 8.1 does that (visible in the TouchBar simulator). They add a global key to control the debugger (Pause/Resume program execution, toggle breakpoints…) while you're in your app, and away from Xcode: https://cl.ly/0v0z3b2S3Q0a

I guess it's a matter of choice, but we see Paw as a visual tool that makes it easy to setup a request (or a set of requests) to iterate quickly when developing an API or discovering a new one. Because of that, we try to keep actions intuitive and keep scripting as a last resort (JS scripts & extensions are available in Paw too, btw).

I know from experience as an iOS developer (then Python backend guy) that when working on a given project, our mind is already full of business logic. We don't want to add another level of complexity due to the tools we use. And we're writing enough code elsewhere to not want to write code in an app.

As of scripting used for "unit" testing, we have thought about it many time for Paw. And while we will do something somewhat related in the near future, it's a slippery slope. A robust API should have unit tests written with mocks and be part of the server code, not a few assertions made in a 3rd party app. We're quite biased here: many users want this feature, but we don't want to encourage bad practices (as it may be interpreted by some as "ok let's not write proper tests, there's Paw for that").

Anyway, that was to share my point of view as a Paw guy :)

If you're trying to import Postman collections into Paw, that's easy https://paw.cloud/docs/migrate/postman (all requests, grouping, environment variables, etc. will be preserved). Once imported, you can even generate a Swagger https://paw.cloud/extensions/SwaggerGenerator

I cannot agree more on this :) The first time I saw Insomnia last year, I found it already very well designed. It had a smooth UX on most basic actions and, I have to say, a fun use of the ".rest" domain name!

I'm the founder of Paw https://paw.cloud and I can safely say that building a good UI is a lot of work. While Paw is built on native Cocoa/AppKit (OS X app framework), the challenges with web are different, but the amount of work is always here. Each custom control, tweak on the text fields and other sorts of custom behaviors are taking a lot of time to imagine, design and implement. But it's a lot of fun too!

Clearly Insomnia is one of these apps where by just landing on the website you know that it's made my someone who has a good taste and who pays attention to details. As of the app, most common Mac shortcuts are working. And the fact that you cannot open the Chrome console (Cmd+Shift+I) or select text outside of user inputs are a proof of a well polished product.

It's often hard to make a point about polished UIs because it's highly subjective and it's common to see people wanting to compare only "raw features" between two products.

I'm not a big fan of Electron apps, and Paw and Insomnia are somehow competing (one native, full-featured with extensions and dynamic values, team syncing…the other being a more lightweight version), but I must admit that Insomnia is nicely made! :)

All fixed! It was a nasty bug, and a terrible UX. A one-liner to fix, but hard to find :) Sorry about that! And thank you to bring that to us, aavotins!

Bugfix version Paw 3.0.5 has just been released https://paw.cloud/updates/3.0.5 (you can update from the app from Paw menu > Check for Updates…).

I'm with you on this, the wide use of the word "API" to designate Web/HTTP APIs is wrong. But we have to admit that if you talk with someone saying "we're build an API that does X", everyone will understand it's a web service, not a C++ library ;) So in the end words are just ways to communicate ideas…so we went for the simpler "API" wording. -Micha (from Paw)

While we ask to create an account at purchase time, it's never needed for trials. Also, to work with Paw for Teams and share projects, an account is required as it obviously needs an authentication scheme for access control… -Micha from Paw

Thanks for the nice feedback, and sorry for the trial window inconvenience. That's clearly a bug, we don't want to buzz users in any way except at app start time in the welcome window. Will look into this bug right now, and find a fix. -Micha from Paw

Thanks for the feedback, John! As you're referring to dynamic values as integer values in JSON requests, it's clearly something we will fix. It was planned for Paw 3, but we had to drop features to keep a reasonable timeline. What we will be adding at the same time, is the ability to have dynamic values that return "objects" (or lists) so in a JSON, so you can dump a subtree.

About the OS X support, we haven't changed the requirements at all for this release. Paw is OS X 10.10+ (Yosemite+) since Paw 2.3. So maybe you had an earlier version? If you were prompted to update with no warning, that's a bug. Sorry about it! Will investigate…

As ing33k mentioned, Paw isn't an automated testing tool (at least not yet), but rather an app where you can experiment with your or others APIs to check if things are working, and have a visual feedback/confirmation of what you're doing.

But that's actually a great question. We are asking ourselves the same here at Paw: should our app offer a testing/assertions feature?

Our own server backend is in Django using the Django REST Framework (it's an amazing tool btw) and clearly unit testing done inside the web framework is the right thing to do. Good frameworks have mocking libraries, and unit tests allows you to exercice all parts of the code (not only API facing). So why testing in an app like Paw? And should we encourage "bad practices" with a new feature that encourages users to have request/response assertions in our app instead proper unit tests?

First, everyone isn't writing tests ;) And sometimes maybe for good reasons (quickly putting together an MVP…). Assertions can be a quick alternative before writing proper unit tests. But mostly, we were thinking about assertions in Paw as a great way to do quick integration testing. For example, we've released Paw 3 recently, pushed server updates on an hourly basis, and we had no way to verify after a deploy that all the website's pages were up and that API endpoints were behaving as expected. Sure, the CI was saying that tests are passing, but who knows if someone has changed settings on AWS or on 3rd party tools (Stripe, Algolia…)? We would have loved to have assertions ourselves…

As the founder of Paw, I'm certainly biased, so I'll stick to the facts. Paw has "dynamic values" which lets you inline computed components in any field of your request: useful for pointing to values from other requests, previous responses (parsing is done on the fly, no need to refresh), which is useful if you want to send back an auth token returned by a previous request. Dynamic values can do also stuff like MD5/SHA hashes, HMAC, URL/hex/base64 encode, timestamps, randomizers (Chance.js, JSON schema faker) with no code required (you can write custom JS snippets too if ever needed). For example, we once demo'ed the Algolia guys that their custom HMAC-based signature for client-side search was doable with no code. So, if you have the need, you can do custom stuff easily.

Also, extensions (many are built by users) are bringing lots of extra features we would have not thought about ourselves: https://paw.cloud/extensions/

Environment variables in Paw can be nested or computed (with "dynamic values" described above). It can be useful, for example, to have an "Auth" variable that contains a pointer that accesses the "user.access_token" JSON path from inside the latest Login request, so you can later simply point to the "Auth" variable everywhere else. One other thing about envs, is that you can have independent groups of environments: a typical example is you have a "Server" group with envs called "Prod", "Staging", "Local" and independently a setup with user credentials or variables that are more like static globals (AWS Keys, etc.)…

Now regarding to the team syncing service, "Paw for Teams". It has branches, snapshots and full history. In a dev team, it means one dev can experiment stuff on the schema for API v2 while others are fixing bugs on API v1, and when API v2 is ready they can seamlessly merge the new updates back to the v1 branch. Also, we've made the choice not to be real-time synced, because it doesn't fit well to software development: when I'm experimenting stuff with an API I don't want others to be polluted by my temporary garbage. So instead you "commit" changes only when ready. More about Teams here: https://paw.cloud/teams

Last but not least, Paw locally encrypts with a randomly generated symmetric passphrase all credentials you enter in your projects, that means your server keys, access tokens, etc. are a lot safer. And now that you can (optionally) sync with Paw's backend, we certainly don't want to have your secrets in cleartext on our infra. As passphrases are never uploaded (obviously! but by default stored in OS X Keychain), it's the users responsibility to safeguard them and share them with their team (on 1Password or similar).

We have actually two ideas in this area. First, as you mentioned, assertion testing. We've recently published a workaround (as a joke, but it's actually working :D) https://blog.paw.cloud/posts/secret-path-to-paw-assertions/ but a real alternative is coming next.

Second, we are currently brainstorming around the idea of a good automation app. So somehow the two ideas may merge. We're not sure yet what would make sense for automation, but for assertions testing, for sure it's in the pipeline!

-Micha from Paw

That's very true :) You can write custom extensions for Paw, and they can be then shared with the community.

But anyway, there's already a HAR importer, you can install it here as an extension https://paw.cloud/extensions/HARImporter

Also, we're working on a powerful API format transformer that we will release more officially soon, but it's already on GitHub: https://github.com/luckymarmot/api-flow That will allow us to release exporters for Swagger, RAML, HAR soon as well as formats of other clients like Postman and DHC Client.

If you're curious about writing an exporter/generator though here are some steps: https://paw.cloud/docs/extensions/create-code-generator

(Disclaimer, Paw guy here…)

Thanks, Eddie! That's really a kind feedback! But we're a whole team now ;)

Yeah, we're aware of this :( we need to spend time polishing those styles! -Micha from Paw

Well, Apple purposely killed Apple Events making them impossible to be sent from sandboxed apps. While I'm not a fan of JavaScript as a language, it has the advantage to be commonly known and I think if it gets more used for app scripting it can be powerful. Sketch seems to be moving from CocoaScript to JS…

Thanks for the mention! What makes Paw different is dynamic values which lets you access/parse data from previous responses and compute anything you want. It's a simple way to do visual programming for your API testing. Also today we're introducing full encryption for users credentials. Also, Paw is a native Mac app, and we love the look and feel it has. (disclaimer: I'm Paw's founder)

All depends on what you call a "great thing".

Sorry for the trouble :( If you can, we'd love to hear more details about the bugs you had. You can contact us via our support page: https://luckymarmot.com/paw/support Thanks a lot!