DEV Community

loading...

A few problems with Facebook's API you might wanna know

I'm Luis! \^-^/
a short bio.
・4 min read

This is my first dev.to post! I'm a little shy, but @katafrakt's post about his experience with Facebook's API motivated me to write this post based on my experience.

Facebook's API is great, it allows you to interact with the platform in many ways and many services use it mainly to get data from Facebook. However, the more you use it, the more you notice there are a few downsides. I want to be as clear as possible and describe some key downsides that have affected me.

I hope this article helps you if you're considering to use Facebook's API or you're already using it.

Sudden changes

Unlike most humans, Facebook doesn't fear change. It encourages change. In some cases, they will massively ban people, tell them it's a bug and a month later tell them they were banned after hundreds complained! I know this is related to Instant Articles, but it's still about the Developer Platform. If you're planning to monetize with them, bear this in mind.

In some other cases, they will suddenly reduce their API rate limit. What happens when hundreds complain because their code is now broken? After an entire month, tell them it's not a bug and it's suddenly fixed for everyone!

The very tough App Review

If you want to request some extra data from Facebook (beyond the user's email and name), you will need to request a permission from Facebook. This is great. It's called app review. You will tell them which permissions you want and a reviewer will verify that your app is using those permissions correctly. Sounds good..., in theory.

The problem is, this process is expected to last for about 2-3 days, but can last from weeks to months and lately there are a lot of developers complaining in their group because their user base is still waiting.

That is, if you're lucky enough to have a company or work for one, because the app review requires you to be a verified and legal business. And by verified, I mean verified by Facebook, which is an extra process. You'll need to upload a company's legal document and sign a contract.

If you're an independent developer who's building something using Facebook's API, and your product does things like posting to facebook pages (or requiring contents from Facebook pages), ads management, or data from your users, you will need to be a company before releasing it to the world or manually add your users as "testers" so they can access those features.

This creates a chicken/egg problem. If you wanna release your product into the world (and later become a company), you will need these permissions from Facebook, but to get the permissions from Facebook, you first need to be a company.

I can't say this is good or bad. It has affected me due to my projects, but this decision was taken after the Cambridge Analytica scandal, so it seems justified.

Problems when coding

Facebook's API is pretty flexible. It uses GraphQL, so you only request the data you need. However, in some specific cases, there are a few things that are not mentioned in its documentation.

For instance, if you want to upload a photo story to a Facebook page, you need to make a POST request to {page-id}/photos} with the param url:

curl -i -X POST \
 -d "url=https://www.facebook.com/images/fb_icon_325x325.png" \
 -d "caption=test photo upload" \
 -d "access_token=<user_photos_user_access_token>" \
 "https://graph.facebook.com/v2.11/me/photos"
Enter fullscreen mode Exit fullscreen mode

This url parameter needs to be a public image on the Internet. This makes it impossible to upload things from localhost or just a private image. But before going to Facebook's headquarters to complain, there's the source parameter, which is only mentioned in the {page-id}/feed page:

a

This has led me (and probably some other people) to upload things to another website if they wanna test their app from localhost.

In addition, if you want to upload multiple photos, you will need to make a request per each photo, which will help your app get rate limited faster.

Final advice

  • Be ready for breaking changes. A cool trick is to send yourself an email any time an Exception is thrown in production.
  • Your rate limit is not per-user. For every user, you can make up to 200 queries per hour. So if you have 2 users, a single user can make 400 queries. This can be good or bad depending on your project, but it also means a single user can break your app for everyone else just by pressing F5 enough times if you're not careful enough, so get your cache ready.
  • Don't sell your users' data to a third-party.

Discussion (0)