Ask HN: Does anyone enjoy working with Facebook's Graph API?
4 comments
Same here. Plus...
- There are many things you cant do with Graph, so I'm still sticking on using the old REST Api.
- Facebook OAuth 2.0 implementation is incomplete, e.g. no refresh access_token method provided.
- Current support for iFrame Facebook.com apps is premature.
With all these, they even planned to remove old authentication method & going full force on iFrame end of this year. Hopefully they really can fix all those problems by then.
- There are many things you cant do with Graph, so I'm still sticking on using the old REST Api.
- Facebook OAuth 2.0 implementation is incomplete, e.g. no refresh access_token method provided.
- Current support for iFrame Facebook.com apps is premature.
With all these, they even planned to remove old authentication method & going full force on iFrame end of this year. Hopefully they really can fix all those problems by then.
I actually enjoy working with facebook's open graph api, BUT Using the PHP & JS SDK is a nightmare. I wrote my own class in PHP using curl, all data is returned in JSON which for me makes things simple. Retrieving the access token and authenticating each user can be handled a number of ways. Ever since they updated there policies, you are now allowed to store all of the users info once they allow your "application". I've seen alot of people complain when they use the new SDK's, but I see no reason to go that route...I think the best way whether it be a application,fan page, or external site is to present your app first, let the user actually see it and not FORCE them to allow it (which 90% of most apps do)...Once they peform a action, either redirect/ or popup/iframe to the authorization url;. I use the 'offline' permission so the access token for each user doesn't expire. Once they allow it, pull any info you want by a simple curl request, then store all there info(including access token) in your DB. Simple as that! There are only a few things I dislike, there like/comment buttons, and how you are limited to using either there iframe or xfbml (which is still an iframe).
This is about par for the course. I've integrated facebook into many an application, and found the same: Facebook's API is buggy, their developer support is nonexistent, and digging up current and relevant results from google is challenging.
I can think of quite a few things Facebook could do to improve the experience of developers using their services, but people are already doing so in droves, and their competition is withering, so I don't see much of a chance of this improving dramatically.
Expect incremental improvements as they reach out into the general web more and more. For example, as bad as the current API is, the old one was worse.
I can think of quite a few things Facebook could do to improve the experience of developers using their services, but people are already doing so in droves, and their competition is withering, so I don't see much of a chance of this improving dramatically.
Expect incremental improvements as they reach out into the general web more and more. For example, as bad as the current API is, the old one was worse.
That's exactly what I experienced (and still do) while working with Facebook APIs.
Sometimes, it is better to search StackOverflow first.
The Graph API got a lot of great "reviews" but I don't know if anyone actually used it first before giving it praise. On one hand it's great in theory, but on the other hand it's horribly broken and poorly documented.
As a developer this is how things usually go.
1) Something isn't working as I expect so I look at the docs.
2) Realize the behavior isn't documented and search on Google.
3) Click on numerous results linking to Facebook's forum to read about lots of others having the same question - Facebook rarely replies or clarifies.
4) Implement a hacky work around because I'll never know if it was on my end or theirs.
Am I the only one with this workflow?