The Dangers of Relying on Facebook
blog.pixamid.com
The Dangers of Relying on Facebook
1–10 of 44 posts
Re: The Dangers of Relying on Facebook
#2Well, it is increasingly becoming a world where we rely on 3rd party servers like Facebook, app approval process from Apple, etc. I wonder how much more complex things are going to get in future
Re: The Dangers of Relying on Facebook
#3As a business, it will always be a bad idea to completely rely on another entity outside your control, whose interests are very likely to be misaligned to yours.
By all means leverage, Facebook (and Twitter and others) sign on and APIs, but if you are building a business on a single one of those, you are completely at the mercy of their whims, any incompetency, and changes in business practices.
Re: The Dangers of Relying on Facebook
#4I would honestly never rely solely on one system, unless that system was my own. You never know what might happen in a years time. Everyone might realise that Facebook is actually worth £10 and it just drops out the sky altogehter.
One of the developers here was building a newsletter system recently and they wanted to use just one 3rd party mail system to manage the user lists and groups etc. I stressed that we must make the system independent and to store the lists of users and groups ourselves and only replicate to the email marketing system. That way, if we ever fell out with the email marketing software we could just open a relationship with another company and replicate the same information there.
As a company, we never implement something without sitting down and talking about the pro's and con's first. Don't get me wrong, we don't have meetings for the sake of meetings but important matters we take the time to discuss.
When we planned our CMS, we took 2 weeks to plan the system and how it would work. We are 18 months into the development cycle and the only thing we can think of that we would do differently is to use url routing over our own url engine. It's not even a massive change to implemement so we are lucky. The 2 weeks planning has saved months of re-factoring for future.
We now have news, galleries, ecommerce, content driven pages, personalised url campaigns, newsletters, e-newsletters. The list goes on. All with no regrets!
It's unfortunate that a company has to suffer bad planning and bad decisions, the main thing is learning from them
Re: The Dangers of Relying on Facebook
#5I would honestly never rely solely on one system, unless that system was my own. You never know what might happen in a years time. Everyone might realise that Facebook is actually worth £10 and it just drops out the sky altogehter. One of the developers here was building a newsletter system recently and they wanted to use just one 3rd party mail system to manage the user lists and groups etc. I stressed that we must…
We knew well the risks going in, but still sucks when you run into the worst-case scenario. It certainly moved forwards our plans to get in alternatives.
Re: The Dangers of Relying on Facebook
#6I would honestly never rely solely on one system, unless that system was my own. You never know what might happen in a years time. Everyone might realise that Facebook is actually worth £10 and it just drops out the sky altogehter. One of the developers here was building a newsletter system recently and they wanted to use just one 3rd party mail system to manage the user lists and groups etc. I stressed that we must…
We knew well the risks going in, but still sucks when you run into the worst-case scenario. It certainly moved forwards our plans to get in alternatives.
What was the developement time on the app compared to if you had implemented a full system with photo upload etc?
Was time a factor?
Re: The Dangers of Relying on Facebook
#7Facebook API client author here (http://restfb.com). In my experience, you've got to be extremely careful/defensive when relying on anything from FB. Undocumented breaking changes are commonplace and no one on the FB side seems to care very much, possibly because they've got a de facto monopoly for the time being, or possibly because community notifications/documentation/etc. are boring next to sexy engineering problems.
Parroting the article, I know: unless your entire app is Facebook-centric, be careful of tightly locking it to FB. If you must tie yourself to FB, think long and hard about doing so first and if you proceed make sure you've got a mitigation plan in place if things go south.
Re: The Dangers of Relying on Facebook
#8Earlier quoted context omitted.
We knew well the risks going in, but still sucks when you run into the worst-case scenario. It certainly moved forwards our plans to get in alternatives.
What was the developement time on the app compared to if you had implemented a full system with photo upload etc? Was time a factor?
Sure, it was a factor. The whole backend was built in 3 months, photo upload would have added another few weeks. But again, we aimed not to do that at all, wanted to be more virtual. At least until we heard form enough users that they wanted that option.
Re: The Dangers of Relying on Facebook
#9It seems that neither Apple nor Facebook is particularly attentive to the developers who build on their platforms once the app is released. Curious models for companies whose success is largely due to the developer community.
Re: The Dangers of Relying on Facebook
#10I'm working on a side project which needs to access a large sample of images to do some magic with the provided target image. Since Facebook has a good store of images, I'd chosen to use Facebook login (and to access user photos and profile pictures of his friends).
With the increasing reports of Facebook horror stories, I'm redoing the backend to be generic so that I could easily integrate a new login system (twitter or my own) if something goes wrong.
As per my project requirements, Facebook is the best option. So, the only care I'm taking to avoid get flagged by Facebook spam detection algos is to ask for as less permissions as possible from the user and avoid posting on walls without user confirmation.