3 ms·

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 (financial

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 5y ago
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.

neura 5y ago

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.