We know it makes more sense for most people having their social networks built to have a first version built very quickly and test it with the target user group or the market, but we have recently had experience with building social networks where the focus was on coming up with an architecture that will scale up to 10s of millions of users economically and effectively. We did an analysis of all the options available to us, and the following is a quick summary of our findings and recommendations.

Goal

To select a platform/framework which will allow scaling to 10s of million users for a social application.

The core issue here is Database Scalability and Flexibility. We’ll touch upon both one by one:

Database Scalability: As it turns out, perfectly normalized, flat databases with absolutely no data/information duplication are not essentially right for applications that need to scale to a huge user base. Such a database structure needs excessive computation and a lot of table joins, which end up getting computationally very expensive as user base grows.

Database Flexibility: Complete control over database structure is required if one is to design an application that is needed to scale to a huge user base, as with time, different clustering and partitioning schemes might be required to help the application scale horizontally.

Platform Assessment

The following is an assessment of Elgg, Drupal and Symfony on the above parameters:

ELGG: Due to a very flat and normalized database structure, the only way to scale horizontally with ELGG is to duplicate the database using MySQL replication on multiple servers. The negative with this approach is that it ends up duplicating the complete database, with the result that each machine running a copy of the replicated database will have to be very powerful server, rendering the solution expensive. (MySQL clusters is a standard way of doing it)

Drupal: Similar problems as ELGG with Drupal, but database is not as flat and normalized as ELGG. Scaling up in a similar manner as described for ELGG wity MySQL clusters would probably be cheaper with Drupal.

Symfony: Allows us to use a custom database structure. We can design the database and replicate it as we like. Symfony also uses its own query/object caching mechanism, which is efficient. As an example, the Yahoo bookmarks site supports 20 million users on Symfony.

Proposed Solutions

Solution 1:
Get deep into the ELGG code and customize the database interaction layer so as to support our own database, that can be designed and partitioned as we wish. The problem that this approach comes bundled with is that subsequent ELGG updates/releases will not be directly usable by us, and we will have to manually merge them into our ‘custom ELGG’. The positive of this approach is that ELGG plugins will work on our ‘custom ELGG’ with none or very little changes, if any.

Solution 2:
Build the solution ground up with Symfony, with our own custom database design that allows us the flexibility to partition it as we like. 

Recommendation

Our recommendation in a case where you are looking to scale up to 10s of millions of users would be write everything from scratch (and not use a ‘platform’ like ELGG/Drupal), that allows you to customize and tweak anything and everything. Symfony seems to have a good reputation for enabling creation of very large websites, and so, we would recommend using Symfony as a framework.

With this experience in the background, Mobicules is now capable of designing, developing, deploying and maintaining rich kiosk multimedia applications and kiosk management infrastructure.

We did a talk at the Facebook Developers Garage, Delhi on why deferring a call to require_login() can be good for your Facebook application. Here’s the presentation.

Here is our Barcamp Delhi presentation about ELGG, the open source social network platform. Hope you find it useful. We are providing ELGG based social network development services and ELGG customization/plugin development services, so please get in touch with us if there is anything we can do for you.   We’re currently developing a plugin for ELGG, and we’ll be posting about it very soon. So watch this space. 

Introduction to ELGG, the Open Source Social Network Platform

View SlideShare presentation or Upload your own. (tags: barcampdelhi barcampdelhi5)

We did a talk in Barcamp Delhi on Facebook Application Monetization Case studies, which generated a very good response from the attendees. We had a lively discussion that ended up taking quite a while longer than the allotted time. Here’s the presentation.  

We have been doing Facebook Application Development for quite some time now, and many of our clients come in with queries about how to best monetize on Facebook. The presentation above might throw some light on answers to that question.

Facebook recently announced its Connect program, and we at Mobicules are really excited about the possibilites. There is already a good amount of buzz about Facebook Connect, and we’re talking to a few of our clients about how this can fit into their scheme of things, and can make their web applications more useful and more “sticky”.What Facebook Connect does is, it allows users to connect their Facebook profiles, friends and privacy rules to any site.

What that would mean is that a website which was not social until now, would suddenly come alive, with the user’s Facebook Social Graph being instantly available on the website. It looks like a lot of privileges available to Facebook Application Developers till now would now also be available to stand-alone websites.

 We think this is a very sensible balance between
    (a) Developing a stand-alone website, attracting users, getting them to invite friends and get them all engaged, and
    (b)Developing an app for Facebook that can use Facebook’s features and data, but now has no independent presence.This is going to make a lot of sense to a lot of people.

We’re eager to start working with our clients on this.

Google’s OpenSocial defines a set of open API, which developers can use to build applications that can be hosted on websites that are “OpenSocial Containers”. OpenSocial containers are websites that have provided implementations for the OpenSocial API, and plugged the implementation with their data, effectively making their data available to applications which use the OpenSocial API. This opens up a great possibility for website owners who have any kind of social data, making them ideal candidates for hosting social applications. Social applications on a website can take a user’s engagement with the website to a whole new level.

How does one convert an existing website to a Social Container? Thats an important question to ask, and as it turns out, its not really too difficult. But before we get into that, it is important to understand a few things about the Google development platform in general.

Google has had, since long before OpenSocial, a widget platform that supports widgets called Google Gadgets. Google Gadgets API enables hosting of widgets on the iGoogle page, and provides APIs to access data from various Google Services like Google Maps. What OpenSocial does is, it extends the list of APIs to introduce APIs that make social data from a social container available to a social application.

Due to the reasons above, Implementing an OpenSocial Container broadly requires implementing the following two components:
1. Gadget Server providing the Gadgets API - The Gadget Server implements the Javascript Gadget API which allows Google Gadgets to be hosted and run on the Website

2. SocialData Server providing the RESTful APIs for servicing the requests from OpenSocial Gadgets (Social Applications) - The SocialData server would connect with the website’s server at the back-end, and provide implementations of the RESful APIs to be used by the Social Applications.

As it turns out, doing the above is not excruciatingly complicated really. Shindig comes to your rescue here. Shindig is an open-source implementation of the Gadgets Server and the OpenSocial API. Once you have Shindig running on your server and plug with your website, your website will be able to host Google Gadgets, and service OpenSocial API calls. You’ll have to plug in the implementation of the APIs with your websites’s back-end database to enable the APIs to access the data.

So there! Make your website an OpenSocial applications host, and engage your users with new and interesting functionality.

We think Dialog Boxes are the most underused among features provided to developers by the Facebook Developers Platform. We find that Dialog Boxes, if used, are used mainly for issuing alert messages on User Actions. While it is very reasonable to use Dialog Boxes that way, there’s a lot more Dialog Boxes can do.

Dialog Boxes are a very good way of taking user input, validating it, and submitting it to the server without having the user navigate away from the page where he performed the action that opened up the Dialog Box. This keeps navigation, simple, compact and very very intuitive. Have a look at the use of Dialog Boxes we’ve made in iAspire. We use Dialog Boxes for almost all user actions where the user needs to enter any additional input after having taken the action.

We recently had a requirement from one of our clients to build a fairly complex dialog box that was a complete menu system that would allow the user to navigate a list of objects arranged as a tree, read details about them which would pop up in boxes inside the Dialog Box, and finally, purchase or add one of them to some sort of a cart. We thought it would be just about impossible to do it with a Facebook Dialog Box, but thought we should try a few it out. And know what, its all possible from inside a Dialog Box!

We’ll post the link to the application when we have released it, and a few tips/caveats/gotchas too. Till then, have a look at the documentation .

We haven’t found anything with the Facebook Developer’s platform to be as intriguing as Templatized Feeds. Templatized Feeds were released by Facebook with an assurance that Feeds which are properly constructed would also land up in the News Feed of those friends of the user who sent out the feed who haven’t installed the application. Now that creates a great viral possibility, and we are among the many developers who went ahead and took the pain to modify their feeds to suit the Feed Template formats.

But with no results. We haven’t yet seen our Feeds landing up on non-application users’ News Feeds. We investigated into this, and here’s what we think is critical ot successfully publishing Templatized Feeds to a large number of users on Facebook:

1. Possibility of Aggregation: The TitleTemplate and BodyTemplate fields of the feed must be simple to aid aggregation. Best practice is to have everything other than the {active} parameter in the feed unchanged from feed to feed. The {target} field should not be used, as it reduces the possibility of aggregation.

2. Links: All links in the feed should be accessible to the viewer of the feed without having to add the application. Facebook analyzes the click-stream of the user once he clicks on any of the links in the feed, and records it if installation of the application is needed to view the content behind the link. Forcing an install from any of the links would put the Feed into Facebook’s bad books.

3. Quality of Content: All links in the Feed must point to pages which are relevant to the content of the feed. This means linking everything to the About page of the application might not help. This implies developers might have to put in a good amount of effort into making some pages from their applications viewable without the user having to add the application. Many leading applications seem to have done this, and we’ve done it for iAspire too here.

There’s no guarantee even after you’ve done all the above that your feeds would land into the News Feed of non application users. But without having implemented the above, it seems, there IS a guarantee that your feeds won’t reach too many users ! Take your pick.

We’re back with some cool new features with iAspire. We have been listening to our users, and have just put in a few of the most wanted features. Here’s a quick overview:

1. Create your own Aspirations: We have just modified this feature to do away with the moderation because all you users had been adding really great Aspirations. You can click the “Create an Aspiration” button on the top right corner of the page to create an Aspiration.

Continue Reading »