Our most recent endeavor into social networking applications was to create a full JavaScript driven application on top of a REST web service layer on MySpace, with the intent on having the application portable between multiple OpenSocial compliant containers (e.g. MySpace to YAP, MySpace to Orkut). 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 JavaScript. We wanted to use the OpenSocial JavaScript API to see what we could do with it, learn more about it and really see what viable options are available over the use of a server side API with regards to portability.
Our application was built, published, and ready to move to its next container. We had been switching between Orkut and MySpace on a regular basis during development when either of the containers experienced downtime or decided to push out some new caching initiative that caused us no end of pain. Our next task was to take this new application and push it to YAP (Yahoo! Application Platform). YAP is an OpenSocial 0.8 compliant container that uses Caja to secure user generated JavaScript and libraries. Caja was an initiative that MySpace was going to implement back in April of 2008 but pulled out of. I’ll talk more about Caja in future posts. In any event, we began moving the application over and immediately ran into some issues with the front end JavaScript. Our JavaScript libraries and large portions of our program control JavaScript would not cajole (to make secure JavaScript using Caja).
What now?
The full client side application was a great experience and we nearly reached the limits on browser capabilities to handle this sort of front end, but now it was time to build the application in a way that would make it portable no matter what container, OpenSocial compliant or not, that we were moving to.
So, we replaced a lot of the JavaScript libraries that were generating our dynamic tables, charts, and handling our event streams with strict HTML / CSS, implemented dynamic flash charts which accepted user data as JSON, and moved a lot of our client side code to a server side PHP controller layer. What little JavaScript we had left we module tested against Caja to make sure that all pieces Cajoled properly. We used Smarty to template all of our application states and expanded our web service layer to bundle user and application data into a single callback.
Or final application model became a highly portable, modularized, scalable application.
Lessons Learned
JavaScript and libraries have their place in programming on their 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, that type of approach usually works in your favor. In the case of social network programming, or any programming done on top of a black box environment, and truly to build portable applications that can be easily deployed over dozens of different containers, this approach has its drawbacks. Flash, server side templates and REST web service layers are just some of the ways we were able to meet the requirements of a portable application. Once we stopped relying on the container & client side compliance and more on our own scalable services, we met all of our goals and were able to port our application.
– Jonathan LeBlanc
No Comments, Comment or Ping
Reply to “Social Networking Application Portability
What We Learned the Hard Way”
You must be logged in to post a comment.