Alex Pooley's Blog

Why don't you subscribe to my blog while you're here? I'm a freelance web developer and I blog about Ruby, Rails, and business online.

Go ahead and subscribe to my RSS feed. Thanks for visiting!

I’ve been looking in to developing an application for social networks recently. Here are a few points of interest.

Pre-built Authentication System

w00t! Tired of writing yet another authentication system? Disappointed by the lack lustre take up of OpenID, +associated technologies? Well screw them. Whether you like it or not, the plebs among us are more likely to log in to a social network to authenticate than your “yet another damn password to remember” authentication system, or “I can’t believe this is supposed to be easier” OpenID authentication system.

Write For Popularity

You too can play the social networks, in the same way that Gordon “fuck me” Ramsay plays the camera. Give people what they want by crawling through the masses of information about applications already available on the social network sites. Want to know the most popular dating, gaming, news related application on Facebook? Check out the application directories.

OpenSocial

OpenSocial is a lot of hand waving and not very much substance… yet. OpenSocial is the promise of writing code once, to a standard interface, and having it run on all social networks. The problem right now is that you need to get in to the copious private beta’s to test your applications within OpenSocial compatible containers, and then who knows if you are then allowed to unleash your application to the rest of the social network. I’ve got an eye on you OpenSocial, get back to me when you’re ready please.

Lightweight

One of the cool things about developing applications on social networks is that you can make them very lightweight by fobbing off the processing to the client’s browser, and the storage to the social network persistence layer. Seriously. Social networks have a storage layer, per application, per user. Want to record the win/loss for a user playing hangman? Stuff it in the persistence layer of the social network. Want to grab a collection of a user profile pictures? No problem, grab the URL from the social network and tell the client’s browser to grab the image from the URL. Facebook have a javascript library so you perform a bunch of stuff without ever having to touch your server.

The only problem you will find is processing data. If you want to track your users then you are probably best to use a database on your server side, rather than the persistence layer. Also, if you want to bridge data access across social networks then you also probably want to store data on your own server. Your storage decisions are going to depend on the type of application you are building.

It’s worth noting that Facebook have the Facebook Query Language, or FQL for you acronym obsessed tech heads. It’s like of like a cut down SQL that you can use to query the Facebook data. I haven’t looked in to it much as my application has no need for this, but it looks very interesting.

Conclusion

So far it seems not too hard to develop for social networks. I found it a little confusing to understand how my application plugged in to the rest of the social network but once you jump in it’s fairly straight forward. I also, and am still, finding it a bit of an effort to understand what information is available, and what my application is allowed to do. For example, I don’t want to spam my users friends but I do want to market effectively.

That brings me to my final paragraph. There’s a bit to be said about the maturing economics of social networks. IMHO the economics of social networks are still in their infancy, but the power found in a network of friends combined with the established user base leaves a lot of room for further development. In my next post I will discuss marketing to social network users. Social networks are a marketers dream. You may be surprised with some of what I have to give away, so subscribe to my blog you lazy bastard.