As others have said, I have had the misfortune of working on a project that used the FB API and relying on a feature that just inexplicably stopped working right around the time we were supposed to go live.
I was already personally uninterested in FB when this happened, but it gave me concrete belief of two very simple realisations:
- Tying your success to the whims of a third party company's developers is going to end in tears
- A motto like "Move fast and break stuff" is just an attempt to re-brand their fucking terrible development practices in a way that junior developers will treat as a positive thing.
I found Facebook docs and APIs to be really good, until they changed one which completely broke a revenue-generating app and didn't post any notification of the change until a week after it had already gone live.
That was a few years back, maybe they're better now. But I doubt it.
Both Facebook and Twitter are a complete dream compared to Valve's API for Steam and Team Fortress 2. Working with that is a complete nightmare, if it even provides a fraction of the capability you need (which it almost certainly does not).
They are still pretty bad. I'm struggling through a Unity integration right now where we need to use the latest Facebook plugin for Unity, but all their examples and tutorials don't compile with it because they renamed interfaces and the like.
You'll pretty much need to dig into the source, IRC is unlikely to be helpful. Documentation is basically nonexistent as well. With that said...it is what you're looking for and nearly every substantial bit of code built around Steam has been created using that library or the Node variant.
I worked on FB integration where a feature being used was disabled and the API replaced with a new one between our product freeze and release (actually the old API was closed a week and a half before the replacement was in place). If I was working at a smaller company at the time, our team would have had no way of knowing WTF happened, other than it didn't work.
The fact is, even with a large corp to corp relationship, you still can't absolutely rely on API consistency... it's pretty sad, but true... Netflix, Twitter, FB, Google and others have changed/revoked APIs before with minor to significant impace.
This is part of the reason why you shouldn't try to make applications designed to scale/adapt for years... design the simplest thing that does the job, and in as modular a way as possible. Avoid "enterprise" patterns as much as possible in favor of the simplest thing that works and is cheap/easy to replace if/when needed. It doesn't mean don't test, consider performance or write good code, just don't rely on it being around, and over-invest in that it likely won't.
You never know... a piece of software I once wrote to test our own product turned into its' own product and pieces of it are still in fortune 100 deployments... It's horrible, and was a hack to begin with. It didn't even support half the specification it was designed for (only the parts we needed)... just the same, it got the job done.
