I'm hitting a login wall; is there a way to access the content for people who don't have a Facebook account?
Alternatively, is there another page that tracks the status of the issue? I found Platform Status [1]; or perhaps "JS SDK and Social Plugins Failure" [2] is more accurate.
For the record, at the moment the submission points to a discussion on Facebook Developers forum [3].
The link the op used is to specific issue complaint thread. At the present time 3:37 EST the only communication from an official facebook responder is:
Hi John,
Thanks for reaching out. We are aware of this issue and are currently working on fixing it. I'll update this thread when I have more information from the team.
Thank you for your patience.
Regards,
Fatma
The rest is a bunch of people complaining of the same issue.
If it has been down that long and that's the only official response, then things must be pretty bad. Either the situation, or FB's communication skills. Neither is good for FB's users, er, products.
Most of the issues on that dashboard don't seem related to the JS SDK, e.g. "Increased latency on marketing insights API" and "Instagram comments webhooks event delivery traffic drop". It's a blended view of every(?) Facebook developer product but you'd usually calculate 9's for each individual product.
The problem here is that the JS SDK encompasses all of their products. They don't have a different script or bundle to download for each thing. You just configure your code to point to their JS SDK url, with some params for which version you want, how you want to use it (xml, json), if it should use cookies or some other tracking method. Then it sends you what they think you need based on those params along with your app id so they can see your app configuration, all in one bundle.
This makes it very complicated to say what is actually down or unavailable, which is why I'm guessing the status is "degraded performance", not "down" and they're not calling it an "outage", because technically other parts of the SDK are completely unaffected.
To say that anything in particular is down, they'd have to list a set of API endpoints that are down or a set of very specific features. This is to their advantage though as [1] as already noted, they don't have to say that their SDK is "down", since it's technically not and [2] other people are still going to argue that "hey, it's up for me".
End result, they don't really care how anybody else feels about it. What are people going to do, move to another platform? Stop using facebook to generate traffic and thus revenue? :eye_roll:
after having been involved in multiple products that relied on facebook, i would not be surprised if this was just their way to let developers know they discontinued the sdk. But don't worry they write a blog post when they bring out the successor in a few months.
I don't know or use the Facebook SDK, but would it be possible to simply disable it and continue running, but without the features it provides?
Previously I've used Google Tag Manager to simply disable external Javascript service when they went down. It saved us multiple time, because we worked with small service providers who doesn't really know anything about the internet, but also in two cases where AWS was unavailable. Rather than having to do a code change and a redeployment, we could just disable a 3. party temporarily.
Maybe the Facebook SDK is typically integrated to deeply to be something you can just disable. It the other comments are correct, and it's down frequently, then maybe you should design to run without it, even if it's just for short periods of time.
> I don't know or use the Facebook SDK, but would it be possible to simply disable it and continue running, but without the features it provides?
The beauty (or ugly, for some) of JS is that it depends on how you use it. If you just call the initialize function (which seems to be down, somehow?) of the FB SDK in the top scope of your page, all code below it is invalid. If you're including it as a script, that script will fail. If it's in a response to some onload event, the rest of the onload body will not execute either.
Not to say you should always expect errors from any 3rd party libraries unless you can guarantee it won't throw, that's just basic error handling.
It's funny to me. A while back there was a thread on HN about the SDK going hay-wire and taking apps down with it. I sometimes wonder how much damage (financially, technically and socially) a single "shutdown" command can cause.
Seems developers don't bother to test/handle certain failure scenario. Because this API or this server will be available until the heat death of the universe and will never fail.
Also shows FB can, at will, essentially DDOS entire apps just by causing a few failures. Quite a nice position to be in for...Leverage should we say? :P
P.S and a tip to devs:
Please test your apps to enure if a third party component dies, your entire site isn't useless without it. It's okay having "stripe" as the gateway for your entire business to make money but you're essentially putting all your eggs in their basket.
Also, if you use third party JS scripts (caching providers), test that if something isn't loaded you have a fallback (perhaps a locally served version, just do that anyway). It's amazing how a script request just doesn't work and well...Your entire site/app is now dead.
One problem here is that the specific way in which the API is down right now (for an app that I work on, at least) is that when you make a login request through the JS-SDK, to get authorization to use other features/APIs, it never responds. The listener is not unavailable, but the API never responds, so from our point of view, we call their JS SDK login function, which takes a callback, the callback is never called. The best we can do is set our own timeout that gets deleted in the callback and if that doesn't happen before the timeout callback is called in the callback, we go down another path, either displaying an error or doing some other fallback code, but this login method is almost always used to get access to another API, so it starts with a user wanting to do something that some time later they'll be notified that they can't. That's just a bad user experience with no other way around it, if they can't quickly return an error.
Also, _WHY_ do these large scale API providers think that just letting the connection hang is in any way acceptable. Their load balancer, cache layer, proxy, literally anything in front of their API can return an error immediately instead of just waiting for the API. Even just returning a 504 for gateway timeout (which is probably the right thing to do) would be better than just sitting there and never returning anything.
Server not responding appropriately. Well, technically, for some endpoints, it's just not responding at all. In the client side javascript, you call a function and pass it a callback and the callback is never called because their API never responds. No timeout or anything, just never calls your callback. The method is used for getting permissions for a user so you know what other calls are available to them. The docs for the method show no way to get the status of the call other than the callback passed in. https://developers.facebook.com/docs/reference/javascript/FB...
It’s too bad the core website didn’t go down with it. I believe the majority of users, at least those in the USA where FB is based, would be better off without it.
A week-long FB outage would surely result in a very interesting study of society’s response and adaptation to said event.
Especially during the pandemic it would be nice to have something that facilitated online communications with people I know IRL. I've never understood how to use it, whenever I go on I see someone's post and like it maybe go to comment only to realize it was from five days ago. People talk about getting into huge discussions and spending tons of time on there, I mostly see a handful of semi-stale posts, a handful of fresh ones, a handful of comments on a few of them. Maybe it is my friend group that is the problem? Maybe it is my infrequent usage? Maybe you have to use it a lot to get anything out of it?
The other problem is that I would not have the same conversations with my conservative relatives as my liberal friends, and it feels awkward that everything is visible to everyone.
With a less walled garden service and with interoperability encouraged (and they'll never ever embrace it due to greed) the service being down (and hey remember when fb went down and took out Instagram and Whatsapp with it?) wouldn't be so consequential for a lot of people
31 comments
[ 2.1 ms ] story [ 28.1 ms ] threadEdit: I guess maybe https://developers.facebook.com/status/issues/49265292218744... is more precise so we'll change to that instead.
Alternatively, is there another page that tracks the status of the issue? I found Platform Status [1]; or perhaps "JS SDK and Social Plugins Failure" [2] is more accurate.
For the record, at the moment the submission points to a discussion on Facebook Developers forum [3].
[1]: https://developers.facebook.com/status/dashboard/
[2]: https://developers.facebook.com/status/issues/49265292218744...
[3]: https://developers.facebook.com/support/bugs/484663959337678...
Hi John,
Thanks for reaching out. We are aware of this issue and are currently working on fixing it. I'll update this thread when I have more information from the team.
Thank you for your patience.
Regards, Fatma
The rest is a bunch of people complaining of the same issue.
[0] https://developers.facebook.com/status/dashboard/
This makes it very complicated to say what is actually down or unavailable, which is why I'm guessing the status is "degraded performance", not "down" and they're not calling it an "outage", because technically other parts of the SDK are completely unaffected.
To say that anything in particular is down, they'd have to list a set of API endpoints that are down or a set of very specific features. This is to their advantage though as [1] as already noted, they don't have to say that their SDK is "down", since it's technically not and [2] other people are still going to argue that "hey, it's up for me".
End result, they don't really care how anybody else feels about it. What are people going to do, move to another platform? Stop using facebook to generate traffic and thus revenue? :eye_roll:
In reality, FB is just being highly transparent with issues and I should applaud them, but that's a lot of yellow and red.
Previously I've used Google Tag Manager to simply disable external Javascript service when they went down. It saved us multiple time, because we worked with small service providers who doesn't really know anything about the internet, but also in two cases where AWS was unavailable. Rather than having to do a code change and a redeployment, we could just disable a 3. party temporarily.
Maybe the Facebook SDK is typically integrated to deeply to be something you can just disable. It the other comments are correct, and it's down frequently, then maybe you should design to run without it, even if it's just for short periods of time.
The beauty (or ugly, for some) of JS is that it depends on how you use it. If you just call the initialize function (which seems to be down, somehow?) of the FB SDK in the top scope of your page, all code below it is invalid. If you're including it as a script, that script will fail. If it's in a response to some onload event, the rest of the onload body will not execute either.
Not to say you should always expect errors from any 3rd party libraries unless you can guarantee it won't throw, that's just basic error handling.
But if they discontinued it, then they have little reasons to put money into improving it.
Seems developers don't bother to test/handle certain failure scenario. Because this API or this server will be available until the heat death of the universe and will never fail.
Also shows FB can, at will, essentially DDOS entire apps just by causing a few failures. Quite a nice position to be in for...Leverage should we say? :P
P.S and a tip to devs:
Please test your apps to enure if a third party component dies, your entire site isn't useless without it. It's okay having "stripe" as the gateway for your entire business to make money but you're essentially putting all your eggs in their basket.
Also, if you use third party JS scripts (caching providers), test that if something isn't loaded you have a fallback (perhaps a locally served version, just do that anyway). It's amazing how a script request just doesn't work and well...Your entire site/app is now dead.
Also, _WHY_ do these large scale API providers think that just letting the connection hang is in any way acceptable. Their load balancer, cache layer, proxy, literally anything in front of their API can return an error immediately instead of just waiting for the API. Even just returning a 504 for gateway timeout (which is probably the right thing to do) would be better than just sitting there and never returning anything.
https://downdetector.com/status/facebook/
A week-long FB outage would surely result in a very interesting study of society’s response and adaptation to said event.
The other problem is that I would not have the same conversations with my conservative relatives as my liberal friends, and it feels awkward that everything is visible to everyone.
It's a project I set up a while back to track changes to the FB JS SDK