APIs that developers should know about
econsultancy.com
econsultancy.com
The thing is, if you're building a startup, you want to deliver value to your customers as quickly as possible ... you know, so you don't die.
Customers don't care whether you used an API or rolled the functionality yourself. For an early stage startup, implementing or troubleshooting back-end functionality you could have outsourced to an API is, to a first approximation, a waste of time.
but, couldn't you make this argument about many things? your company's payment gateway? your bank? ISP? server host? etc.. your business will hit the breaks if there are any major hiccups with the providers of any of these services.
i mean, its contextual, of course. if you've written a twitter app, its different. its not an app being built with the help of an api, its an app being built specifically for an api. but a single business makes use of lots of services, and an api is just a service.
- Zencoder - I'd use these to minimise costs at the beginning, but I'd build my own system along side it and replace Zencoder with that system once I started to earn.
- Twilio - Spend the time you'd use learning Twilio to learn how to configure up Asterisk instead. Set it up with multiple SIP providers with multiple PSTN gateways.
- Saplo - I'm not familiar with these guys and it's not fully clear what they do to me.
- Adaptive Payments - Paypal? You're kidding right. Don't use Paypal. If you absolutely must use them, make sure you have a drop in replacement for when they fuck you over.
- SimpleGeo - No need to use a web service for this. You can get IP to geo data for free nowadays, and every programming language has a library for it.
To a few of your points:
- Twilio - Spend the time you'd use learning Twilio to learn how to configure up Asterisk instead. Set it up with multiple SIP providers with multiple PSTN gateways.
Seriously? The idea that going from zero to production on Asterisk takes roughly the same time as doing it with Twilio is risible.
- SimpleGeo - No need to use a web service for this. You can get IP to geo data for free nowadays, and every programming language has a library for it.
Again, preposterous. That's not what SimpleGeo does, even the briefest look at the homepage shows that: http://simplegeo.com/
I guess the hard part is really determining what is trivial vs what is worth letting someone else take over. Some people may look at the above services and feel like they look pretty easy - and then a week or a month down the line they realize there is more to it than they first thought.
Other aspects people often don't think about - dashboards and admin sections usable by a non-developer.
I'm not vouching for any of these services as I have never needed to use any of them, but I would definitely guard against blind "not invented here" syndrome.
I agree to some extent that you should not rely on other services without having any kind of replacement, but to say that you have to build everything yourself seems rather ill-informed advice...
If it will take me a couple of months to replicate something which already exists as a web service, I will usually use the web service. If only temporarily.
None of the web services mentioned so far on this page seem significantly difficult to replace, and suggesting that people use them seems rather ill-informed advice...
Remember that building it is not the only cost; you also have to consider the costs of maintaining it and keeping the servers running.
I wrote this article. I think it's more accurate to say "Building software on top of someone else's web api can be a really, really bad idea" -- if you don't do due diligence. I've written about the perils of building on top of consumer web platforms in the past, and personally think there's far more risk in building apps for, say, Facebook and Twitter, than incorporating into your own product a commercial API that you've vetted reasonably well.
Developers/entrepreneurs need to be pragmatic. New ventures that spend all their time and money trying to eliminate risk usually fail; the ones that succeed instead try to manage it. When working to get something to market to see if it will fly, it can be a huge mistake to invest in building low-level functionality from scratch. Most developers/entrepreneurs, for instance, aren't going to build their own video encoding engine. Sure you could use ffmpeg, but out of the box ffmpeg is hardly Zencoder. The time, cost and functionality advantages of Zencoder certainly outweigh whatever risk there is that Zencoder would go out of business in the near term.
In short, it's about cost and time-to-market. Reinventing the wheel usually increases both. So unless you have unlimited resources and already have a strong presence in a market, it's far better to bring a lot of this stuff in-house after you've validated that there's a market for your product and it's making some money.
I signed up to get access to the API's there, but does anyone on here have experience using them?
Uploadjuicer can be replaced with imagemagick. Should be less than a days work to write a web service if you really need one. Host on AWS and bring up more nodes if you need to process more images than one node can handle.
Recurly looks like it offers real value. I would use Recurly, but with the intention of replacing it with my own custom system after a while.
Pusherapp - Trivial to replicate in house. Their front page also refers to browsers which don't support WebSockets as "crap"