A Developer’s thoughts on Facebook’s API & Customized Apps for Brands
Thursday, April 29th, 2010
Part one of a two part series focusing on Facebook’s API and using it to create Facebook applications for brands.
When Facebook first released their API and developer platform, it was a big step for companies trying to leverage the capabilities of social networks. Developers could “easily” build on top of the Facebook platform, submit it to their application directory, and suddenly a simple application is a click away from millions of users. Take this model, apply it to mobile applications and it sounds awfully similar to the successful iPhone app marketplace. It sounds easy enough but it’s another thing to execute and keep developers happy. The success of Facebook’s developer platform was not as simple as creating a public API and a centralized area for listings. Facebook needs to ensure the barriers to entry are low and road maps are communicated properly.
So, what has Facebook done to ensure a high adoption rate for application development? The one aspect that is overlooked with the release of an API is the “platform”. As a developer, to me the developers platform is more than an API, it includes features like: official forums, support groups, ticketing systems, standard news releases, and sample libraries in common programming languages. If Facebook had just released the API documentation it’s unlikely as many companies would have adopted Facebook development.
From a developer’s perspective, Facebook has been a leader in providing a real platform for 3rd party application development. The first thing most developers do when they want to learn a new tool is download the “sample code”. This is usually followed by reading up on the documentation and then asking questions. When a new API or tool does not have working sample code, documentation and an official forum, the barriers to entry become too high. This results in higher costs for development which ultimately makes the adoption rate very low. From the start, Facebook provided working sample code, documentation with examples, and an official forum. All of these elements together have helped create a strong developer community.
While the Facebook platform is great, there is a “dark side” with the API. The one word that can sum up the major pain point for the Facebook API is “change” or “deprecation”. When an API feature is “deprecated”, that means it has the potential to become dated and could be removed down the road. Facebook has an interesting methodology on removing and releasing new features. They usually offer forewarning when a feature is about to be removed, but there is no backwards support for older versions. You cannot build an Facebook app for the API from last year, it needs to work with the API from today and the one coming in a few months. The only exception is right now with the newly launched Graph API. Currently, canvas applications should be built using the older REST API as the Graph API does not support all features… yet.
As frustrating as this can be for development, in the short and long run I think it’s a smart approach for the Facebook platform. Aside from saving development time on Facebook’s side, it forces companies to evaluate their applications at all times to ensure it’s utilizing all the newest features. The only major downside is cost and time, as every Facebook application has to be updated constantly.
The value from developing Facebook applications is well worth the work involved with maintenance and API changes. With a few lines of code, you can tap into API features that update user walls, news feeds, and status.
Part two of this series will offer a case study that highlights the process of achieving that fine balance: using the latest offerings from Facebook’s API and doing so in a way that can also be maintained for future revisions down the road.
