Enter a search term such as “mobile analytics” or browse our content using the filters above.
Check your spelling or try broadening your search.
Sorry about this, there is a problem with our search at the moment.
Please try again later.
Last week, I wrote a post detailing five APIs that I think developers should know about. The reason: they offer useful functionality that most developers (and entrepreneurs) aren't going to want to build from scratch.
The post hit the Hacker News front page and sparked an interesting discussion. One participant, 'Figs', wrote, "Building software on top of someone else's web api is a really, really bad idea."
He or she went on:
If you don't control the system it runs on, then you are completely at the mercy of someone else's business. If they go broke, your software goes down. If they have a technical problem, your software goes down. If they decide to change some aspect of their software, your software goes down. Please, think twice before you build your businesses out of this deck of cards.
In theory, Figs makes a good point: there's risk involved when relying on third parties. And relying on third parties to provide key functionality for a product is something that most of us would probably rather avoid. But does that mean that building a product using third party APIs is a bad idea? Absolutely not, and such thinking is dangerous.
Eliminating Risk versus Managing Risk
Risk is something most of us face in one form or another on a daily basis, and it's present when building a new business or product. As noted, building a business that relies on a third party API does entail taking risk. Figs is right: if the vendor behind an API you rely on goes out of business, or has a major bout of downtime, it could take you down for the count as well.
But there's risk involved in building a product that doesn't rely on someone else's API. If you choose to implement functionality in-house, for instance, you might have a hard time building something that scales as well as similar functionality offered through a third party API. Depending on the complexity of the functionality required, you could also be taking on huge financial risk.
What's better: relying on a third party vendor, or spending a lot of money building functionality that might not scale? That's a difficult question to answer, and it's difficult to answer because it reminds us of the fact that risk can almost never be eliminated. The approach you take to minimize certain kinds of risks is likely to create additional risks of its own. This highlights a key lesson for developers, entrepreneurs and established businesses alike: success requires risk management. Risk elimination, however, is like the pot of gold at the end of the rainbow; it simply doesn't exist, and trying to eliminate risk will often lead to decisions that misallocate precious resources.
Pragmatism > Perfection
In a perfect world, all the functionality your product ever needs could be implemented and maintained in-house easily, effectively and cheaply. But we don't live in a perfect world. The real would calls for pragmatism. The advantage of pragmatism: you often get things done that you never would have otherwise.
When building a new web application that incorporates telephony functionality, for instance, you might, in theory, be able to bring all of that telephony functionality in house instead of relying on a third party like Twilio or Tropo. But that's not necessarily easy. Building telephony functionality from scratch is in many cases going to be time-consuming and expensive. Even open source solutions, such as Asterisk, will often require considerable investment.
If everything you currently need can be found in a third party API, the question becomes: should you spend time and money trying to build in house, or should you avoid reinventing the wheel? If you have limited resources, reinventing the wheel may not even be an option (if you hope to launch of course). But even if you have significant resources, there's good reason to thoughtfully weigh the advantages of 'perfection' (read: owning and controlling everything) against the potential cost and time-to-market advantages of implementing using a third party API.
Why Third Party APIs are Great
In my opinion, the best thing about third party APIs is that they free developers, entrepreneurs and businesses from having to invest in low-level functionality before such an investment makes sense. Many, if not most, new products fail, or need to be modified heavily before they succeed, and I've personally witnessed new ventures waste significant amounts of time and money building complex functionality in house simply because they made the assumption that they'd be successful and therefore it would all pay off in the long-run.
In today's highly-competitive business environment, getting to market quickly and cost-effectively is often a prerequisite for success. When you can avoid significant investments in low-level functionality to launch, iterate quickly and validate the demand for a new product, you have a significant competitive advantage vis-à-vis competitors that, for whatever reason, have chosen or been forced to allocate their time and money building functionality that anyone can implement more quickly and cost-effectively using a third party API.
When implemented sensibly, a third party API will rarely prevent you from bringing functionality in house down the road when circumstances may warrant. And when due diligence is performed and a solid vendor is selected, third party APIs can even ensure that functionality is being provided more reliably, freeing you to focus on your product.