New Facebook blog category

I’ll start this new blog category with a blunt statement. I really dislike Facebook. It’s a wildly popular website/platform/application, but it’s very poor quality software. That said, I plan to write applications that integrate with Facebook (and other sites like Twitter, Google apps, etc) so I’ll document in this section my thoughts and experiences with coding into the platform.

While this intro is follows my typical article style of blogging, I’m going to try to write a larger quantity of shorter entries on this topic.

Facebook developers write code that conforms to the Facebook API. The API includes definitions of functions for reading and writing data to user pages. Unfortunately the API is very complex and has been in constant flux. Facebook privacy policies have been in flux. A lot about Facebook is always in flux. Facebook provides their own implementations of their API so that people writing JavaScript or PHP can quickly build applications for the platform. Compared to a situation where every developer writes their own implementation of the API under their application code, having a standard implementation (an SDK) is very helpful.

For .NET, the world has been left to create its own SDK. Facebook seems uninterested in the .NET development community. Personally I think this is a very bad business decision which seems largely influenced by techno-religion. While the Facebook management and developers are entitled to their opinions about technology, they are running a business where their mission to generate revenue should take precedence over how they think people should write code. There have been several community attempts at creating an open SDK based on the published API. The most popular of these is the Facebook Developer Toolkit (FDT). Another noble effort that didn’t reach a critical mass of user/developer support is the .NET Facebook API Client by Daniel Schaffer.

In April 2010, I was looking into the .NET Facebook API Client project at Codeplex. Daniel was apparently concerned about the status of the project and the state of .NET development for Facebook in general. He posted a rather self-deprecating note to the project forum titled “I Suck“, with a short project status update and notes on some of his concerns. I responded with my own thoughts and we had a few more exchanges to discuss the current state of the art. Feel free to read those notes to get more insight into how we’re seeing things.

Around that same time, at their F8 conference, Facebook announced a major change to their interface with the introduction of the Graph API. The name comes from the hot buzz-phrase “social graph”, which is the concept of following deep links between people, places, and events. Twitter, Google, and many other services are dedicated to social networking for the purposes of defining and making use of everyone’s social graph. Facebook has been talking about API changes for months but this was their big announcement. Here is what the Facebook Platform Upgrade Guide says about the Graph API:

The new Graph API is replacing the old REST API as our primary server-side API. Despite our focus on this new API, the REST API will continue to work.

And here is how the introduction page defines the Graph API itself:

The new Graph API attempts to drastically simplify the way developers read and write data to Facebook. It presents a simple, consistent view of the Facebook social graph, uniformly representing objects in the graph (e.g., people, photos, events, and fan pages) and the connections between them (e.g., friend relationships, shared content, and photo tags).

People can debate how long the “old REST API” is going to be supported but it seems clear to me that the forward direction must be with the Graph API. This means someone like me who is contemplating new development for Facebook with .NET will suddenly find all of the SDK / API implementations to be completely useless. Projects like FDT are already in a state of chaos. Let’s assume they do get all the bugs fixed and features implemented. The next step after achieving a fully functional implementation is ultimately a complete re-write. Why should I or anyone code into a SDK based on an API that is almost certainly going away?

With remarkable agility, Daniel started a new Codeplex project: FBGraph.NET. As of this moment, the project is still not published. Daniel added me as a Developer to the project and gave me access to the code. After some amount of disorientation with the new API and the impressive volume of code in the new SDK, I was able to connect to Facebook with a test application and retrieve some data. FBGraph.NET seems to be the only .NET implementation of the Graph API. It has a long way to go but it’s a very good start.

Upcoming posts to this blog category will include notes about my experience with this new SDK (and whatever other tools are available) and with the creation of various Facebook projects for fun and profit. Comments and questions are always welcome.