Consuming the Facebook API: TIL

Fri, Sep 7, 2018

A young entrepreneur ( hi Gino 👋 ) came up to me to set up a portal focused on local businesses. In the first iteration content should be sourced from an authorized user’s Facebook Business Page(s).

That means implementing Facebook OAuth. One little disclaimer: I don’t have a Facebook profile. Nor am I particularly fond of the big F. Being a complete n👀b in this social domain I braced myself for a lot of reading and tinkering.

Cambridge Analyticerrr

In recent months Facebook pushed through several changes in how a party can consume it’s data streams. That’s a good thing. But it did cause a stir in the API’s documentation, processing times and overall ease of use.

The drawing board

If we are to hook a user into logging in with her Facebook account and extract Posts from their Facebook Page feed we have to ask for the correct permissions.

The permissions we need are:

• public_profile
• email
• pages_show_list
• manage_pages*

* requires a Facebook app review`

With these permissions in place we can log a user in, request basis personal information and interact with the Pages.

Not sure if we need pages_show_list as that functionality should be covered by managed_pages. It is worth noting that we don’t need or want write permissions. We only want to pull data from Pages, but this seems like the way to go. Looks like overkill to us.

It might sound intrusive to new users. We expect that we need to educate the user prior to asking for the manage_pages permission. But we might be overthinking that.

Storing the data

Once we receive data from Facebook we store it via our models in our database layer. The payload of Facebook is stored as jsonb in a Postgresql database. So we do not need to stay on top of every new possible data structure that might come our way. Today or in a somewhat distant future.

We try to do as much as possible on background workers using Sidekiq.

Setting up a Facebook App

Facebook is a big monster company. That shows when you take a look at all the possible configurations. You can set up a web, mobile, desktop, … Facebook app. And you can clone that app into a Test version of that same app for your inner testing needs.

A Facebook app comes with an App Id and App Secret. The Secret is used as a seed for User Tokens, which can be used to fetch Page Tokens. You can also opt-in to send the Secret with every API request to tighten up the security.

At this point this all makes sense to me. But it is a lot to take in when you are also reading through the numerous pages of documentation. And setting up a Rails server, with staging environments, with auto deploy hooked into git and so on.

Facebook App Review

Currently our Facebook App is in Review. In order to submit for a Review you have to provide a lot of details about the app:

• logo
  
• policy url
  
• screencast about how your are using certain permissions
• step by step guide on how your reviewer can see the feature in action
• a Test User with a Test Page for the reviewer to use

But this might take a while according to this Support page.

Due to changes to the review process and the high volume of submissions expected, it may take several weeks for submitted apps to complete review.

Excerpt September 2018

Test Page caveats

Getting a Test Page set up for our Test Users was a time consuming task. To be clear, we are talking about API generated Test Users, not fellow human beings who spend their hard earned spare time to check out the fruit of our labor.

There seem to be some bugs that prevent you from creating Test Pages using the traditional forms on FB. The form always complaints that you should add a location when you try to create a Business Page for your Test User.

Once you make use of the Graph API Explorer in the Developer portal everything is ok. Sort of.

Here’s what you need to do: - Take note of the Test User’s Id. - Assign the manage_pages permission to the respective Test User in your Facebook App settings - Use the edit button and click, tap or lick to Get Access Token - Now you are able to POST data to the /{user_id}/accounts endpoint to create one or more Test Pages for your generated Test Users.

Some pointers:

• Wrap the value for cover_photo in a json formatted hash with the value of the URL in a url key
  
  • Like so: "cover_photo": {"url":"https://api.adorable.io/avatars/285/abott@adorable.png"}
    
• don’t use category_enum but use the category key with a numeric value
  • look up possible values with a GET request to the /fb_page_categories root node

To conclude

After all is said and done we are left with a better understanding of how Facebook works. But big blue can be a PITA. Their platform is well documented but the sheer amount of possibillities makes it harder to filter out the good stuff. Some of the error messages where a bit off which threw us of the right track from time to time.

While we wait for the FB approval of the app we are already tinkering with Elastic Search to unlock precious insights and datapoints to the end user.

• Facebook
• Rails
• OAuth
• Elastic Search