In contrast with some other classmates/bloggers, I've only recently even signed up for Facebook....I've been a real social networking laggard, generally seeing most features as time-wasters, but I certainly can't argue with its popularity. It has provided a leverageable platform for application developers to reuse and extend, and has provided a great benefit in facilitating reach to end users.
The architecture of Facebook is interesting to me because it has to deal with some fundamentally challenging issues of trust and privacy, as well as weaving these issues into the constantly changing landscape that is the Web, and I think that the Facebook engineers have done an admirable job.
Obviously, Facebook realized that they couldn't keep up with the diversity and pace of users' desires, and hence the 3rd party application system is the natural way to continue growing the business without having to bear the ongoing brunt of innovation.
The archictecture they put in place to support this is quite clever, and obviously has proven its mettle, as can be witnessed by the abundance of 3rd party content/providers, and users consuming that content.
FQL supported this both by bringing a more familiar "query" paradigm to the API calls, and also by exploiting operation batching to some degree.
The 3rd party application model is an interesting and challenging one, because typically applications are trusted with the content they must display, but in this situation its not the case--similar to asking a taxi driver to drive you to a secret location by blindfolding them! Facebook made this possible, however, by changing the model of data access. With FBML, the application didn't so much process the data, as declare what data should be processed and presented--essentially offloading some of the application's runtime into the Facebook environment.
As the power of JavaScript has grown, its ever growing necessity is inevitable in the 3rd party application environment. Instead of taking an Apple iPhone approach, and reviewing/inspecting and then approving or denying entry, Facebook made the model much more open. Instead of jumping through bureaucratic hoops of a review process, developers must jump through technical hoops, by structuring their browser code within a restricted framework. For a site like Facebook, I think this was a smart choice, because of the rapid pace of such content.
Facebook's architecture gives us a glimpse into one possible future of how networked applications are built. Whereas traditionally the application/developer has been given a great deal of free reign over all pertinent data in a process, Facebook's architecture makes us rethink the validity and sustainability of this paradigm--if applications/developers have access to all data they process, how hesitant are we going to be to provide access to this data, thereby limiting future growth? If, on the other hand, a method of computation and composition can be extended, such as the Facebook architecture, wherein sensitive data is kept within tightly controlled confines, the future of such applications is certainly bright!
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment