I’ve been integrating applications with Facebook for nearly a year and during that time I’ve found it difficult to find reliable documentation, guides, and just a good set of best practices out there. A friend of mine recently voiced similar misgivings which spurred me to write about some of the obstacles I have had to overcome. I’ve aggregated information (with sources when available) about topics I’ve had to deal with when integrating with Facebook. I will break up these topics into a series of posts that will be published over the next few weeks.
- Server side vs Client side (JS) libraries
- Integration Testing with Facebook
- Mailing List, Operation Developer Love, and Reporting
- Other odds & ends
- Violation of the Separation of Concerns (SoC) principle
- Data validation
- Testing is more difficult than it needs to be
For example, if your client is sharing something on Facebook on behalf of your application, then the client will need to download all the information required to construct a Graph API post from your application server. The client will then pass the constructed post object to the Facebook JS library. When a call back is executed the application may now want to track whether or not the post was successful, as well as persist other attributes of the post and the user. Again, this information will need to pass through several boundaries and tiers of your application to get where it needs to be.
More information on proper patterns for integration of systems can be found in the book titled Enterprise Integration Patterns.
When your integration point lies on the client you make your system much more difficult to test. If you want to test your application without the integration it’s more difficult to mock or stub Facebook out of the picture on the client than it is on the server side. I realize that there are numerous libraries out that do allow for control over the client side layer during testing, but in my experience the tooling involved in testing an application that integrates with a 3rd party resource is much easier to setup, stub/mock, and test on the server than it is on the client.
 Post to user feed with the Graph API Post – http://developers.facebook.com/docs/reference/dialogs/feed/#graphapicall
 Immutable parameters in Graph API Post – It’s a typical requirement of applications integrating with Facebook to have a user make an endorsement of something on their user feed. The application can not prefill or modify the user’s custom message in any way (see Facebook’s Platform Policies, Section IV titled “Application Integration Points”, point #2). However, the content of the rest of the posts parameters can be prefilled as long as the user executed a workflow in a way that the parameters are expected to be in the post. For example, when sharing an endorsement of a product of a company, the image parameter post could be a picture of the product itself, the link parameter could be a link to a product on the company’s website, and the action and description text could describe the product in more detail.