101–110 of 185 posts
I can't state this enough. Building your company which heavily relies on an API provided by someone else is risky business. Why are we still in this infatuation stage of ignoring the pitfalls of this?
Earlier quoted context omitted.
Google's App Engine is pretty much a for-profit API. And now they've announced a change in their pricing scheme, which if true, would change App Engine from pay-what-you-use to same-as-amazon-aws-but-pricier scheme, which makes it hugely expensive for a large portion of devs that have built on top of App Engine. And migrating away from App Engine is a total pain in the ass. I truly hope that the blog-post missed impo…
I never liked app engine. To me it seemed like you have to lock yourself into google as a vendor because your application has to be designed for app engine.
I never liked relational databases. You have to lock yourself into SQL because your application has to be designed for SQL.
I never liked python. You have to lock yourself into python because your application has to be designed for python.
Earlier quoted context omitted.
You are making a false assumption. I personally use the FeedBurner API to keep track of feed subscribers, for example, and it was deprecated yesterday.
....and you still have 3 years to use it! (granted no more development will be done on the API.) So over the next three years which is like an eon in web years you can look for an alternative. Frankly Goolge might even bring out an alternative.
You mean, why should you build a for-profit product while relying on someone else's not-for-profit API? I'm guessing you shouldn't! I've seen a lot of neat projects come from Google APIs, but that's as far as I'd taking it. Relying on someone else's good will for the lifeblood of your company is insane. 1 exception, though: Getting started. I could see using Google to get off the ground and then switching to a more r…
in the case of apis, the risk is that there is some probability that the api will go down. the benefit is that you don't have to write your own stuff, and in some cases, the benefit is the entire value proposition of your application. for example, should you use the google translate api? there is some probability that the api will go down. whatever you estimate this probability to be, that's how you have to weigh your benefit. you probably can't recreate google translate, so the benefit is whatever benefit your application provides, or the marginal benefit that google translate provides to your application.
also, consider the fact that all apis will go down, but you can always create value in the interim. no api is going to be around forever, but will html even be around forever? how long is your application going to be useful? maybe the chance that the api will go down in the medium term is low, so that's an acceptable lifetime for your application.
Offering an API, paid or unpaid, is not making an unending commitment to support it forever. If it was, businesses would simply not offer APIs. When someone offers a product or service, they have to right to decide later on to not offer that service any more. That is simply the nature of any business arrangement where you are depending on an entity not under your control. Would the OP prefer that Google and other com…
Nobody is arguing that they don't have the right, but there are social implications to doing so. People have the right to not like them because of it. You also have the right to not write thank-you cards when people do nice things for you, but those people have the right to react to your selfishness.
This was a free service and they're no longer going to offer it, and they're shutting it down in an orderly manner. That's not selfish.
This is more like someone giving you a birthday present every year, and then when they fail to send you one, you write a nasty post about how greedy and selfish they are.
Earlier quoted context omitted.
I never liked app engine. To me it seemed like you have to lock yourself into google as a vendor because your application has to be designed for app engine.
I never liked Linux. You have to lock yourself into Linux APIs because your application has to be designed for Linux. I never liked relational databases. You have to lock yourself into SQL because your application has to be designed for SQL. I never liked python. You have to lock yourself into python because your application has to be designed for python.
Why can't we all be friends and blossom like flowers in the fields?
Earlier quoted context omitted.
I never liked app engine. To me it seemed like you have to lock yourself into google as a vendor because your application has to be designed for app engine.
I never liked Linux. You have to lock yourself into Linux APIs because your application has to be designed for Linux. I never liked relational databases. You have to lock yourself into SQL because your application has to be designed for SQL. I never liked python. You have to lock yourself into python because your application has to be designed for python.
Are these APIs really so unique that they can't code for some other provider's replacement? Is it just that a for-pay translation API, for instance, is too expensive for a product without a solid business plan to use?