

The Facebook Platform Is A Trainwreck - stickfigure
http://blorn.com/post/14840036960/the-facebook-platform-is-a-trainwreck-example-871

======
wwweston
Sometime last fall, Facebook blew away their entire developer wiki. A month or
two afterwards was my first experience seriously engaging their platform since
early 2008, and many of the tutorials and search results out there on the web
still pointed to the smoking remains of the wiki -- which hadn't actually been
404'd, they just lead to Bing searches roughly topically related to what had
been there before.

As best I could discover, the rationale was apparently concern over two sets
of docs -- their own official docs and a community maintained one.

It's less clear what made them decide a half-assed official effort would be a
better plan than combining whatever clearly limited internal resources they
were throwing at the problem with a world of developers that is, despite
persistent stories of abuse, apparently still interested in working with them.

If nothing else, curating and augmenting a community-led effort would have
radiated a considerably smaller degree of contempt for the effort already put
into it.

I kindof suspected at the time that decision tells you most of what you need
to know about how much FB cares about the experience developers are generally
having with their platform, and I have to say, I haven't seen much to convince
me otherwise.

~~~
johnyzee
Which is not just incompetent and unprofessional, but obviously very bad for
business.

Does anybody doubt at this point that Facebook is crumbling under its own
weight? For all their money and hiring they still have a stagnant application
and a trainwreck of a developer platform. Predictable I suppose when you grow
too much, too fast. Well, hope they enjoy the ride until the next market
disruption at which point, tell MySpace I said hello.

------
flashingpumpkin
Sigh. I feel your pain. They've deleted the Python SDK unanounced from Github
two weeks ago. Not really responsible if you consider there were dozens of
watchers and possibly at least as many other sites / projects depending on it.
(Also that's ignoring the fact that their docs state 90 days warning period
:()

 _edit_ Typos, writing on the phone and it's late.

------
cpeterso
Beware building _your_ business on someone else's API. They control it and
they likely don't care about you. The API exists to boost _their_ business.

~~~
latchkey
Unfortunately, that isn't entirely true. There is a huge amount of value in
allowing someone to log into your site with FB credentials. You get their
name, age, sex, _validated_ email and a list of their friends all without
having to ask a single question and more importantly, not write any code to
manage or synchronize that information.

What is incomprehensible is that by offering this authentication system
feature on our sites, we are actually _helping_ FB gain more users and thus
boost their business. You'd think that it would be treated more as a mutually
beneficial ecosystem, but instead is treated like a third party integration
that nobody cares about. Especially when there are bugs.

It really is too bad that FB refuses to take advantage of developers and
business people out there who are willing to actually help their company grow
and are asking nothing in return except for a bit of acknowledgement when
things go wrong.

~~~
gnu8
Stop imagining you're entitled to any of that information from any user,
especially for free.

~~~
ams6110
Couldn't agree more. And to the GP, you may think that having Facebook
authentication on your site is a benefit to both you and Facebook, but it can
also work against you. I for one will NOT use any web services that require
Facebook authn.

~~~
saurik
On the other side, I could just say the exact opposite: I find it infinitely
easier when a site supports Facebook authentication. You can't just say "it
can also work against you" unless you can show evidence that the target
audience of the site, on the balance, will be turned away.

I mean, if we come up with more of these, eventually everyone will find at
least one ludicrous. "I for one will NOT use any web site that requires"... "a
credit card", "watching advertisements", "authentication of any form", or
(probably the only reasonable one ;P) "seeing comic sans".

~~~
wnight
Actually he only needs one example to say "it can also work against you", and
he _is_ that example.

He didn't say "will", or "probably will" even, just "can".

But using FB to login to other sites seems less handy and more like a way to
lose all your accounts when one of them gets hacked, and by concentrating so
much value in a single account you increase the likelihood of it being
targeted.

~~~
saurik
That is like saying chemotherapy "can work against you" by showing a single
skin cell died during the treatment; it isn't "working against you" unless you
lose so many skin cells that the chance of killing the cancerous tumor is no
longer "worth" the risk.

If you accept "single user got angry" then every single thing you can "can
work against you", and the phrase is meaningless: some people hate the color
blue, while some other people hate everything /but/ the color blue. Decisions
need to be made "on the balance", not because there's one angry user.

------
douglasp
I work at Facebook.

We absolutely do care about our API.

We are working as hard as we can to make our API less buggy and more stable.

Over the course of the past year, we have added more tests, more resources and
more tools to this problem than we have throughout the lifetime of Facebook
Platform.

In addition, we are in the process of reducing the surface area of our
platform to a level that allows us to provide a good level of support.
Specifically, we are removing FBML
(<https://developers.facebook.com/blog/post/568/>), deprecating the REST API
(<https://developers.facebook.com/blog/post/616/>), moving to support OAuth
2.0/HTTPs (<https://developers.facebook.com/docs/oauth2-https-migration/>)
across the board and deciding what SDKs we are really going to support. These
changes are painful for us and developers, but necessary to provide the level
of support developers expect.

Ironically, it is the OAuth migration that is responsible for the JavaScript
SDK bug reported in the post. We introduced this bug went we added the OAuth
code path. This bug is on deck to be fixed soon, however (there is a
straightforward workaround in the meantime).

In terms of the source of JavaScript SDK, we are working through the right
approach to ensure that developers get access to the non-minified source
(which I agree we need to do for debugging). It is unlikely that we will do
this via GitHub, but we are looking at just having it off our CDN with the
minified version as an option.

As for the bug process, I'll say two things. First, we now have a dedicated
team of engineers devoted to supporting developers. If you have been
developing on Facebook Platform for a while, the fact that bugs are getting
daily responses is a vast improvement. We have a _long_ way to go, but we are
listening and fixing. I will note that we are still working through the
process on how we respond to various issues and how the bug tool (something we
launched this year) works -- this seems to be evidenced from the post and
something I am following up on. Second, just because the reporter can repro
it, it doesn't mean we can, even with the steps that you provide. Our team of
support engineers tries to repro every single issue that gets reported. Often,
they simply can't and need more information.

I'll close by saying the following:

1\. We care about our developers and the API.

2\. We have done more this year than we have ever done to help developers and
keep the platform stable.

3\. That said, we still have a long way to go and these things do not change
overnight.

4\. If anyone has issue with how a bug is getting handled or any other issue
with Facebook Platform, you can always ping me on Facebook
(www.facebook.com/dmp) or dmp@fb.com.

~~~
psychotik
One other option to look at, if you aren't already, is to freeze new feature
development and allocate most resources to making the platform solid. You
didn't state that in your list above.

You may be correct that you've done a lot to stabilize it during the last
year, but how does that compare with the amount of new features you've added
over the last year? Maybe Facebook just isn't good at producing bug-free code,
and it's time to improve things you do before actually shipping a feature?
Continuing to "ship fast, break fast" clearly hasn't worked when it comes to
Platform - are you doing anything to fix that?

As an anecdote, Microsoft had a similar problems with Security of their OS -
it was a much more severe problem. They took a similar approach to the one
you've outlined, for many years - furiously developing new features while
scrambling to patch security. However, in the early 2000s (2002?), after a
particular severe worm hit computers all over the world, they completely froze
all new development on the OS. They did their famous 'security push' where
almost every engineer focused on security for many months. They revamped tools
and invented technologies to make sure products are more secure out the gate,
and the result was a resounding success.

Developer frustration with the Facebook Platform is very real - a competitor
with a stable API might actually receive a lot of support from the community.
Maybe Facebook needs its own version of Microsoft's 'security push'.

------
iamandrus
The Javascript SDK is atrocious. I was writing a small score submitter for an
HTML5 game I made (for testing, mostly), and they clearly don't care about
their developers at all as the documentation is completely unorganized. I end
up having to _Google_ "site:developers.facebook.com x" just to find a function
that fits what I want my app to do. Also, they refuse to update broken links
to older pages and like you said, refuse to fix certain bugs that are
_clearly_ bugs.

------
poutine
Similar issues in dealing with the IOS SDK, ended up removing support for
single sign on in my app due to it simply not working part of the time.

~~~
adamjernst
Having used it in several apps, the iOS SDK is an absolute mess.

Part of this is the absurd complexity of it: there are sign-on flows for going
to the Facebook app if installed, or to Safari, or to an in-app web view.

~~~
brendn
Part of this has to do with the complexity of storing cookies in WebKit. The
SDK wants to redirect to the FB app if it's installed since that is pretty
much guaranteed to have the user's credentials. Safari is next most likely,
since it will have the user's session cookie stored. Finally, the in-app web
view is the fallback of last resort.

This complexity seems to be an attempt to save the user from entering text in
a tiny form to sign in. I don't know that it makes an actual user's life
easier, but it certainly doesn't help the developer.

------
latchkey
It is simply amazing that something that is clearly a bug would be marked as
WontFix without so much as a explanation of why.

------
gregholmberg
Everyone complains about the poor documentation, but my biggest problem in the
last six months has been the drunkenly uneven performance of
<https://graph.facebook.com/>.

Our users want their avatars / profile pics, but they don't want 20 second
page load times. Band-aiding the resulting UX into something tolerable is a
large problem for us.

~~~
roguecoder
Asynchronous loading is beyond mandatory for anything requiring Facebook
avatars. We would use lazy loading, like we do for everything else, except
that Facebook is lazy enough for all of us.

------
safetyscissors
I am currently working on an app which uses Three20 and I have to say the way
it integrates into ios projects is kinda crappy. You have to jump through a
lot of hoops to get it to work. They should have made it a simple drag and
drop lib/framework like the majority of iOS frameworks or even just have a
project template.

------
jonmrodriguez
Perhaps someone feeling either charitable or entrepreneurial could maintain a
web service that just wraps the Facebook API, as well as providing bindings
for python and whatnot.

~~~
omegaworks
They'd have to maintain it in perpetuity... this wouldn't be anything a sane
person would do out of charity.

~~~
jonmrodriguez
True. But surely they could charge a minimal subscription fee (say $2,000 a
year) that kicks in above a certain usage threshold . Hopefully many companies
that use the Facebook platform would find it worth $2,000/yr to save their
developers' time and morale.

------
joe_the_user
Twitter?

I'm working on Facebook and Twitter and the latter just seems generally
nastier (ill documented, ambiguous, not based on a simple graph...). A lot of
Facebook the Facebook API is pretty good - well documented, clear and simple.
And however bad Oauth 2.0 might be, Oauth 1.1 is worse. Oauth 1.1 is
pathologically irrational.

And Facebook is only, ONLY directly responsible for THE API ITSELF. If they've
maintained some Java or Python stuff, that's right nice of them but it's not
their main job. If you are complaining about particular SDKs offered by
Facebook, you aren't complaining about "The Facebook Platform", you're just
complaining. When they change the interface (as they've done several times),
then complain.

I think the site's motto probably explains things better "Of course it sucks,
it's made of software".

~~~
iamandrus
> If they've maintained some Java or Python stuff, that's right nice of them
> but it's not their main job.

Because, you know, nobody programs in languages like Java or Python anymore,
am I right? /sarcasm

> If you are complaining about particular SDKs offered by Facebook, you aren't
> complaining about "The Facebook Platform", you're just complaining.

Wait, what? Those SDKs _are_ a part of the Facebook platform... we kinda need
them to integrate FB into our apps.

