

Ask HN: Is relying on scribd's API a big mistake? - edb

I have a web application I'm working on that essentially shares documents within a small niche community. Scribd has done alot of the hard work as far as managing documents go, their iPaper allows me not to worry about storing documents, making them easily readable, etc.. Most of the heavy lifting is done by them.<p>HOWEVER, I am now building a web service that depends on scribd.com for full functionality. If scribd goes down, I go down. If the documents on scribd no longer become available, my service fails. I've already discussed the implications of copyright for my service with the scribd guys and that's not a concern of mine.<p>I've been told that scribd has enough momentum to not have to worry about it, but adding that extra coupling still makes me wary. It will save me LOTS of time and effort though and my release date will be MUCH earlier and alot more flashy and stable. I've decided to go forward with scribd.<p>Am I making a mistake here? I'd like to hear what you guys have to say.
======
mechanical_fish
I'd figure out how to backup the scribd documents so that your users' data
won't get _completely_ lost if and when scribd disappears. You want to make it
_possible_ to recover from the loss of scribd, even if it's inconvenient.

Most likely the right answer is to launch now and work around scribd later. If
your community completely fails to catch on, then you needn't waste time
cloning scribd. If scribd gets you through a year, after which someone _else_
has cloned scribd, you get to leverage their work. If you're really lucky,
that work will be open source.

If nothing else, having your community up will allow it to grow and get stuff
done while you are busy building an emergency failover system for scribd.

Of course, if your community will lose $1m for every minute that scribd is
down, you should consider paying someone to build your own version of scribd.
Indeed, you should probably consider _buying_ scribd, or at least their source
code.

~~~
gry
I'm in agreement. It seems like having the user upload to your
server/hardware, store the original and pipe it into the Scribd API. It'll
afford you the opportunity to move away from Scribd bit by bit. In fact, if
Scribd goes down, you can revert to say a PDF of the original document. It
won't have the bells and whistles, but the info is there...

------
kogir
You already called out the problem: you can only be up as often as all of your
critical partners are up.

If you care about uptime and reliability, you can only partner with well
established, reliable players for core functionality. For example, Google Maps
is a pretty safe partner.

Also, what would you do if they went away? I'd make sure you have your own
copies of every document, just in case.

Now, in all fairness, scribd has been up whenever I've used it and seems to be
continuing to gain traction.

------
WarTheatre
If scribd went out of business tomorrow, how long would it take for you to get
a solution working? How much would it cost?

No, I don't think you're making a mistake, but this is a high risk decision.
Personally I would at the very least look into using one of scribd's
competitors as an emergency solution in case of major downtime, bankruptcy,
etc.

------
echair
The likelihood of scribd suddenly disappearing seems small, whereas the value
of speed in developing new services is large. So seems like a good bet.

