The Facebook Platform Is A Trainwreck(blorn.com)
blorn.com
The Facebook Platform Is A Trainwreck
http://blorn.com/post/14840036960/the-facebook-platform-is-a-trainwreck-example-871
12 comments
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.
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.
The JavaScript SDK is a complete mess. They broke BC when they introduced OAuth2 support.
Their code speaks volumes to the choices they've made as an organization, as well as their technical skills. Let's face it, Facebook is not a software company like Google, MS or even Apple. I know some Facebook Engineers and all of them are average PHP developers.
Like I said, code tells a story, and in this case, unfortunately, it's not a good one.
Their code speaks volumes to the choices they've made as an organization, as well as their technical skills. Let's face it, Facebook is not a software company like Google, MS or even Apple. I know some Facebook Engineers and all of them are average PHP developers.
Like I said, code tells a story, and in this case, unfortunately, it's not a good one.
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.
edit Typos, writing on the phone and it's late.
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.
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.
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.
Stop imagining you're entitled to any of that information from any user, especially for free.
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.
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".
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".
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.
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.
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.
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.
I never said we would 'require' FB auth. It certainly is one of the options though. One click login, not having to remember a bunch of different passwords and not having to fill out yet another registration form is very compelling for a lot of people.
We also provide enhanced functionality based on the data that is made available to us. We only ask for the minimal set of permissions. As a result, we get the data which I already outlined.
Another option which we are supporting, for people like you who won't use FB, is BrowserID. That system only gives us an email address. So, because the site I'm building requires all of the same data that FB already provides us, we still have to force you through a 'registration' process at some point.
I'm curious, what exactly is your fear of FB auth that prevents you from using it?
We also provide enhanced functionality based on the data that is made available to us. We only ask for the minimal set of permissions. As a result, we get the data which I already outlined.
Another option which we are supporting, for people like you who won't use FB, is BrowserID. That system only gives us an email address. So, because the site I'm building requires all of the same data that FB already provides us, we still have to force you through a 'registration' process at some point.
I'm curious, what exactly is your fear of FB auth that prevents you from using it?
I can't speak for him, but I never use Facebook auth to prevent scumbags from getting a bunch of info about me including a list of my friends with no questions asked.
a) What questions would you ask?
b) Why do you trust Facebook and not another site with that information?
c) What do you define as a 'scumbag'?
a) it takes a longer relationship where I'm treated with respect before I trust a site. I'd have to know they weren't going to spam me or my friends, they weren't going to store tons of data, things like that.
b) most of the info I put on FB is fake, I only keep it to untag photos. FB doesn't fit criteria a, haha
c) pretty much everyone trying to get at my social graph
And contrariwise, I never use Facebook auth to prevent Facebook from getting even the slightest amount of information about my usage of other sites that I can avoid giving them.
Don't completely agree. Building an ecosystem isn't just providing an API, its providing an API that actually works. Facebook might have gotten away with a shoddy API (I've created two social apps) that includes inconsistent data and suspect documentation because it was the only game in town. But with increased competition in social, hopefully Facebook realizes it will lose developer patience if it doesn't improve the overall quality.
Here's to competition and anti-monopolies.
Here's to competition and anti-monopolies.
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 [email protected].
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 [email protected].
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'.
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'.
The JavaScript SDK is a complete mess. You broke BC when you introduced OAuth2 support.
Your code speaks volumes to the choices you've made as an organization, as well as your Engineers technical skills.
I know some Facebook Engineers and all of them are average PHP developers.
Code tells a story, and in this case, it's not a good one.
Your code speaks volumes to the choices you've made as an organization, as well as your Engineers technical skills.
I know some Facebook Engineers and all of them are average PHP developers.
Code tells a story, and in this case, it's not a good one.
The problem is not that the API has bugs, the problem is the way Facebook interacts with the developer community. You have a huge problem and it's not something you will fix by writing code.
I don't know what is going on inside FB, but I can tell you what it looks like from the outside: You hired a bunch of junior developers to "fix bugs" in the platform while the Real Engineers go on to make whatever new bug-ridden feature Zuck wants this week. Except that these new developers don't know how the system works and can't even figure out what is or isn't a legitimate bug.
I mis-linked the second bug in the blog post; please examine it again now. Neither bug has been re-opened yet. The 'auth.logout' event still fires on login. This is obviously broken to anyone who has tried to develop a FB app, and yet the FB engineer looks only as far as some internal documentation before dismissing the claim without explanation.
I'm a 3+ year veteran of the Facebook platform. In all this time I cannot say that support improved one bit. Yes, the Graph API is less janky than the REST API, and the documentation is prettier - but in a lot of ways it has gotten worse:
* There is no way for developers to ask for clarification or add their own observations, like there was in the old Wiki docs.
* The old docs at least tried to document error codes and error results. The new docs make no mention of errors whatsoever. And in the mean time you've added three or four different error result formats because even within Facebook nobody knows what an error result should look like.
Sure, you moved "support" over to stackoverflow, which is at least better organized. But the problem was not the software. Today's problem is the same problem you had before: knowledgeable Facebook engineers are not present answering questions. Combined with the sparse and often wrong documentation, this leaves the community playing ridiculous guessing games.
This is a world of difference from the Google APIs I have experienced: Maps and App Engine. In both cases, there are forums where the actual engineers who work on the features hang out and respond to user questions. These people have names and they're not afraid to talk about the design issues involved. If Google+ inherits this attitude towards developer support, we're going to drop Facebook like an abusive spouse.
TL;DR: Answer questions. Respond to inquiries, even if the answer is "I'm not sure yet". Treat documentation as a first-class citizen. And whatever you do, DON'T CLOSE BUGS UNLESS YOU'RE 100% CERTAIN THEY AREN'T BUGS. Nothing pisses off a developer like spending hours isolating a test case only to be ignored or given the F-U of Won't Fix without an explanation.
I don't know what is going on inside FB, but I can tell you what it looks like from the outside: You hired a bunch of junior developers to "fix bugs" in the platform while the Real Engineers go on to make whatever new bug-ridden feature Zuck wants this week. Except that these new developers don't know how the system works and can't even figure out what is or isn't a legitimate bug.
I mis-linked the second bug in the blog post; please examine it again now. Neither bug has been re-opened yet. The 'auth.logout' event still fires on login. This is obviously broken to anyone who has tried to develop a FB app, and yet the FB engineer looks only as far as some internal documentation before dismissing the claim without explanation.
I'm a 3+ year veteran of the Facebook platform. In all this time I cannot say that support improved one bit. Yes, the Graph API is less janky than the REST API, and the documentation is prettier - but in a lot of ways it has gotten worse:
* There is no way for developers to ask for clarification or add their own observations, like there was in the old Wiki docs.
* The old docs at least tried to document error codes and error results. The new docs make no mention of errors whatsoever. And in the mean time you've added three or four different error result formats because even within Facebook nobody knows what an error result should look like.
Sure, you moved "support" over to stackoverflow, which is at least better organized. But the problem was not the software. Today's problem is the same problem you had before: knowledgeable Facebook engineers are not present answering questions. Combined with the sparse and often wrong documentation, this leaves the community playing ridiculous guessing games.
This is a world of difference from the Google APIs I have experienced: Maps and App Engine. In both cases, there are forums where the actual engineers who work on the features hang out and respond to user questions. These people have names and they're not afraid to talk about the design issues involved. If Google+ inherits this attitude towards developer support, we're going to drop Facebook like an abusive spouse.
TL;DR: Answer questions. Respond to inquiries, even if the answer is "I'm not sure yet". Treat documentation as a first-class citizen. And whatever you do, DON'T CLOSE BUGS UNLESS YOU'RE 100% CERTAIN THEY AREN'T BUGS. Nothing pisses off a developer like spending hours isolating a test case only to be ignored or given the F-U of Won't Fix without an explanation.
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.
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.
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.
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.
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.
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.
It is simply amazing that something that is clearly a bug would be marked as WontFix without so much as a explanation of why.
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.
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.
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.
[deleted]
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.
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.
They'd have to maintain it in perpetuity... this wouldn't be anything a sane person would do out of charity.
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.
... and as soon as FB decides to block it ...
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".
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".
> 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.
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.
Facebook is responsible for the Javascript SDK, which is the issue at hand. The Javascript SDK is really the only SDK you couldn't implement yourself since it relies on undocumented cross-domain communication techniques.
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.