Postman is limiting local collection runner to 25 runs for basic plans
community.postman.com
community.postman.com
It uses these amazing things called files. With files you can commit them to a repository of other files where your team can find them.
https://marketplace.visualstudio.com/items?itemName=humao.re...
you can follow the standard RFC 2616 that including request method, headers, and body.
POST https://example.com/comments HTTP/1.1
content-type: application/json
{
"name": "sample",
"time": "Wed, 21 Oct 2015 18:27:50 GMT"
}
This same scenario has played out 10000x with the exact same outcome, yet people keep expecting something different from the next one.
Wtf even is a "local collection runner"?
Something every single request tool can do. A very basic feature that requires absolutely no resources from Postman's servers.
https://learning.postman.com/docs/running-collections/intro-...
Basically a way to integrate your API requests into a headless experience, can be used for things like CI.
Right now, it seems like it only happens a few ways:
- be a giant saas and use your "free for personal use" tier as a loss-lead/way to get devs using you, thus wanting to use you at work, then you charge their work. e.g. github.
- be linux and be a big enough critical piece to where companies actually fund you directly
- pay software engineers oodles of money so that they can have leisure time to maintain the plethora of random FOSS software that's out there
- leech off the social safety nets of other countries and let engineers subsisting off ramen in the netherlands write your foss software
- play the donation-to-COL arbitrage game and write FOSS from a third-world country where a meager stream of USD donations/purchases can sustain you reliably
Pretty much every single one of these except the linux one is pretty awful. And we can't all be Linux. The second least problematic is probably the one where you pay engineers shittons of money and then let them do shit as side projects, but it seems really indirect.
Is not a bad option. Devs won’t pay for tools, but their orgs will. Isn’t that how it should be? My plumber’s employer pays for their Rigid $2k hydraulic copper fitting crimper, for example, because it saves time vs sweating pipes (enabling them to do more jobs, and generate more revenue).
Be the hydraulic crimper of dev tools. Expensive, but generating so much value no one batts an eye at paying for it (obligatory patio11 “you’re not charging enough” reference here). Some people will cheap out and pay $100 for the hand crimper and do their crimping by hand; don’t sell to them, they are not evaluating their time value efficiently (or they simply don’t need your tool).
For a recent example of this: Docker, going from $12M to $100M ARR within a year as soon as they started charging enterprise users.
Why take ownership of the project if when there's no intention of maintaining it from the very beginning? It's almost as if projects like httpbin are detrimental to their business.
Although 2 features that would make this perfect are still open
- Private self-hosting: https://github.com/hoppscotch/hoppscotch/issues/870
- sync collections with git: https://github.com/hoppscotch/hoppscotch/issues/870
https://github.com/usebruno/bruno
It's free, open-source and fresh with some radical ideas challenging the current status quo.
Oh, BTW we support infinite collection runs.. lol..
[1]: https://hurl.dev
but apparenty it's real. https://techcrunch.com/2021/08/18/api-platform-postman-value...
You can also save requests data to git repo.
Github, slack, whatever else. it's a big long cycle. Now I see tools like Postman and the first thing I think is "how do they want my money, whats their strategy financially", things I never thought when I bought a CD-ROM or a one-time license to tools.
this is a dumb change, especially given you're not using any of their resources so artificial constraints on the number of runs makes zero sense.
Well, same way that notebooks are a REPL that remembers things, it's helpful to rapidly tweak parameters in your API calls, flick a menu to point to a different environment, retry requests on your own local instance, etc. Then when you have it all ready, you just save and it's shared with your team, and the non-developers don't even need to learn what a virtualenv is. Even your CI can take advantage of it. Well, it could.
There's "nothing" Postman provides that you can't do with a python script and git, but it lets you move much faster and have a tighter iteration loop.
That said, paying $10/user/mo just to effectively share a bunch of json definitions was always a plan that only made sense with corporate credit cards. With this added artificial restriction, my team is going to be looking for other alternatives.
Dropbox gave a similar degree of convenience and that's why they took off. But once every cloud provider figured out they too can sync files in the cloud, the novelty became a commodity. This plan reeks of Postman being out of actual feature ideas so in their desperation they're just milking whatever they can get out of their corporates through artificial restrictions before "a cloud-sync'd API runner" becomes a software commodity and the lights go out.
Currently working on a project to solve this https://github.com/usebruno/bruno