[HN Gopher] FB JavaScript SDK down
___________________________________________________________________
FB JavaScript SDK down
Author : littleworld
Score : 102 points
Date : 2021-04-30 19:00 UTC (4 hours ago)
(HTM) web link (developers.facebook.com)
(TXT) w3m dump (developers.facebook.com)
| jFriedensreich wrote:
| 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.
| mrweasel wrote:
| 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.
| capableweb wrote:
| > 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.
| dathinab wrote:
| I wanted to write: "Again? They don't learn to use robust
| patterns do they".
|
| But if they discontinued it, then they have little reasons to
| put money into improving it.
| LordOfWolves wrote:
| 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.
| austincheney wrote:
| There is a movie built upon that premise:
| https://en.m.wikipedia.org/wiki/Surrogates
| maxpert wrote:
| People will only discover they can live without FB like I did.
| Never came back to self glorification platform.
| flatline wrote:
| 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.
| annadane wrote:
| Who ever, ever thought "<friend> commented on public post"
| is a good idea? What the hell is that?
| annadane wrote:
| 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
| londons_explore wrote:
| This is client side javascript right? Did they push a bad
| release, or is the server not responding appropriately?
| neura wrote:
| 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...
| aboringusername wrote:
| 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.
| neura wrote:
| 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.
| joecool1029 wrote:
| Mods please update link to
| https://developers.facebook.com/status/dashboard/ whatever OP
| linked is loginwall'd
| dang wrote:
| Changed from https://developers.facebook.com/support/bugs/48466
| 3959337678.... Thanks!
|
| Edit: I guess maybe
| https://developers.facebook.com/status/issues/49265292218744...
| is more precise so we'll change to that instead.
| thih9 wrote:
| 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].
|
| [1]: https://developers.facebook.com/status/dashboard/
|
| [2]:
| https://developers.facebook.com/status/issues/49265292218744...
|
| [3]:
| https://developers.facebook.com/support/bugs/484663959337678...
| MivLives wrote:
| 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.
| dylan604 wrote:
| 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.
| disgruntledphd2 wrote:
| It was most likely looked at by the Dublin/Europe team, and
| passed to SF without a resolution. But yeah, it's super
| bad, especially on a Friday.
| [deleted]
| ChrisMarshallNY wrote:
| FB, in general, had kind of a rough day today.
|
| https://downdetector.com/status/facebook/
| frob wrote:
| By my count from the status page[0], the FB JS SDK has had issues
| for 30 of the past 90 days. That's not even one 9.
|
| [0] https://developers.facebook.com/status/dashboard/
| [deleted]
| schneidmaster wrote:
| 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.
| neura wrote:
| 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:
| im3w1l wrote:
| That's assuming each issues lasted 24 hours right?
| frob wrote:
| I think most of them did since the same issue would be marked
| on the tracker for multiple days in a row.
|
| In reality, FB is just being highly transparent with issues
| and I should applaud them, but that's a lot of yellow and
| red.
___________________________________________________________________
(page generated 2021-04-30 23:01 UTC)