Writing a Social Network
Social Networking is something of a pehnomenon at the moment, with Facebook, MySpace and Bebo (amogn others) leading the public perception of what social networking is all about, although there are many, many others - including the one I wrote for Pitch and launched a little over a year ago.
It’s now been more than six months since I stopped working on the Pitch Social Network, and in the interim I’ve been working on developing a new social networking application. Speaking to some people I work with, I mentioned that I’d been thinking about writing a series of blog posts about Social Networking development, to discuss some of the ideas I have on how such applications should be architected, not just from a software point of view, but from the whole service architecture, including infrastructure, service design and software design.
Everyone I spoke to told me to go ahead, and now that I’m back from a few weeks away in Australia, it seemed like a good time to start.
So, what am I going to be talking about? I’m going to talk about what I see as the basics of the actual design and implementation of a Social Networking website, covering software design, service design, infrastructure thoughts, technical architecture, database design and the like. Whilst I may at times post code, this won’t be a series where I post the entire codebase for a social network, and it’s quite likely that whilst I’ll talk about certain architecture or design decisions, I may not necessarily use them in the site I’m building.
And alongside all this discussion will be an actual social networking site, which already exists on one of my servers. Or rather, there are two versions, a mobile one and a web one, with the only difference between the two being the way the underlying data is accessed. My intention is to write both versions side by side, ensuring that each version is functionally the same, and provides roughly the same experience regardless of device used to access.
Obviously there will be some fundmental differences between the two sites, at least in the plumbing. For example, mobile devices don’t normally support cookies, so the basic concept of a server-side session needs to be forgotten about, which leads on to discussions on how to deal with persistence of information between pages for a single user. And on the web, this type of discussion is moot as there are session-based services that can be used for persistence.
But I’ll try not to get ahead of myself too much in this introductory post, and leave off with a quick rundown of the tools I’ll be using:
For the site development itself: Object oriented PHP (4.3+)
For the database: MySQL 4
Development Tools: Eclipse IDE, Firefox, Opera.
And yes, an early version of the site is already available and running - links coming in a future post :)
February 22nd, 2008 at 1:09 am
Why not PHP5, or MySQL5? Seems odd to start a greenfield project based on obsolete tech.
February 24th, 2008 at 11:14 am
Easily answered :) Whilst I have PHP5 and MySQL5 running in my dev environment, my live servers are currently running PHP4 and MySQL4. Yes, they may be ‘obsolete’ and unsupported, but both these technologies are still in wide use in business - in fact, one major project I worked on recently was done with PHP4 since that was the available working environment.
There’s also the concept of ‘N-1′ as a base platform - current revision minus 1 - as this level of tech is proven to work, and usually has most of the problems sorted out.
On another note, whilst there’s loads of fun stuff in PHP5, there’s nothing actually compelling (other than your ‘obsolete’ comment) that makes it a better choice over PHP4, at least for what I’m working on at the moment. About the only thing I’m missing is stream_socket_enable_crypto(), but since I’m not planning on implementing anything to do with XMPP, that’s fine :)
Going to MySQL5 would be helpful (stored procedures yay!), btu again, what I’m doing is so simple that advanced features are not needed. If I was doing this ‘in anger’ (i.e. as an enterprise development project rather than something for me to do as a little fun thing) then I’d be looking at an entirely different architecture and toolset - which yes, would include PHP5, and would most likely make use of Sybase rather than MySQL5 if I chose to use a model where all data transformation was done through stored procedures rather than at the PHP layer. But that discussion is for another blog post.