Social Networking Application Portability - What We Learned the Hard Way

One of the major initiatives within the partner integration group of the Yahoo! Developer Network is to explore new technologies and methods for improving upon existing application development structures. This technology exploration is used to enhance products and services that we build for our partners in order to provide the richest overall user experience we can offer.

Our most recent endeavor focused on social networking application development. More specifically, we wanted to assess the levels of support offered by the leading OpenSocial containers for raw JavaScript (JS), YUI, the OpenSocial JS API, RESTful back-end architectures, and cross-platform (e.g. MySpace to YAP, MySpace to Orkut) code portability.

To this end, we created a JS-driven front-end and a RESTful web-service for our database and developed and deployed our application on MySpace. The web service layer was used to facilitate communication with our MySQL database but all of the application structure and user interactivity was built using JS. We wanted to use the OpenSocial JS API to learn more about it and really see what viable options are available in the API that may be utilized for partner application requirements in a social networking space.

Once our application was built and published on MySpace, our next task was to push it to the Yahoo! Application Platform (YAP). As many readers are aware, YAP will be OpenSocial compliant and use Caja to secure user-generated JS, including JS libraries like YUI and jQuery, CSS, and HTML. YAP will be one of the first full scale, real-world implementations of Caja. Immediately, we ran into some issues with our JS, namely, current versions of YUI are not Caja compliant. We had used YUI extensively, so our JS would not "cajole."

What now?

Placing the application logic entirely on the client-side gave us a rich development experience, but our JS was not portable and we were pushing the limits on browser capabilities fairly hard. Now we needed to build the application in a way that would make it portable no matter what container we were using, OpenSocial compliant or not.

Previously, we used JS libraries to dynamically generate tables and charts as well as to handle our events. We have now replaced much of this code with strict HTML / CSS generated on the server using Smarty
, and dynamic flash charts using the Yahoo! ASTRA Libraries, which accept user data as JSON. We have moved a lot of our client-side code to a server-side PHP controller layer, which fits right above our web-service layer. What little JS remains has been run against Caja to make sure all the pieces cajole properly. In addition, we have expanded our web service layer to bundle all of our application data into a single callback.

Our final application model is a highly portable, modularized, and scalable application.

Lessons Learned

Raw JS and JS libraries have their place in programming on the web, and can be used to extend an application in many wonderful ways. When you have complete control over the platform that you are building on, and are building applications without much need for portability, the client-side approach usually works in your favor. In the case of social network programming however, or any programming done on top of a black box environment, to truly build portable applications that can be easily deployed over dozens of different containers, this approach has its drawbacks. Flash, server-side templates, and RESTful web service layers are just some of the ways we were able to meet the requirements of a portable application while maintaining highly modularized code. Once we stopped relying on the container and client-side compliance, and shifted more functionality to our own scalable services, we met all of our goals and were able to port our application.