Best practice for data model and architecture

Dec 20, 2007 at 10:39 AM
First of all, this is a great starter kit and nicely put together. It demonstrates the basics of a Facebook application really well. Nice one for putting it out there.

I would like to now take this starter kit and build a real application with it, but I'm not too sure of the best way to structure my own data model, nor the architecture for my project in the "best way".

The Application

Let's imagine we have an application that allows Facebook users to submit food recipes and then comment on other peoples' recipes (this isn't my application, but it demonstrates some key points). This is a fairly simple data model, which could be done with two tables, but I'm going to use three (I want to store member information within my app):
  • Member table: Holds a reference to the fbuserid, some fb user data (name, profile pic, etc), a count of how many recipes that user has submitted and when they installed the application,
  • Recipe table: Holds the information about the recipe (instructions, cooking time, difficulty, average user rating, number of views, etc), plus a reference to the memberId from the Member table,
  • Comment table: Holds the comment data and a reference to the memberId from the Member table.

Adding new users and creating sessions

My assumption is that when a user adds the application we create a new Member record, saving the fbuserid as part of that record. Whenever a user then logs in, we check that table for the fbuserid and log them in, otherwise we need to get them to add the aplication (how do you do this?)

Types of Pages

I would like to have a couple of pages:
  • My Recipes: Where a member can manage their recipes
  • Add Recipe: Where a member can add a new recipe
  • Edit Recipe: Where a member can edit a recipe
  • Popular Recipes: A list of popular recipes
  • Search: A way to find recipes by type, or keyword
  • Network: A list of the most active networks submitting recipes
  • View Recipe: A display of a selected recipe

Key Questions

The implementation of our application now raises a couple of questions:
  • The code demonstrated in the default.aspx, shows how to check if a Facebook user is logged in or not, how to get a AuthToken, and create a Facebook session. I imagine that in a real application, you wouldn't want this code included in every page, but ideally in a separate piece of code that can be included in each page. Based on the basic architecture of the starter kit, the best way to do this, is to create a PageBase class that inherits from System.Web.UI.Page. Every page then inherits from that PageBase, rather than System.Web.UI.Page. If no session exists, then the user would be redirected to a new page called CreateSession.aspx, which does what is currently in place in default.aspx. Does this make sense to do it this way?
  • This Facebook application has two different types of page; one is a page that is only viewable by the logged in member (such as My Recipes, Add Recipe and Edit Recipe), and other pages that are viewable by all logged in users (Search and View Recipes). This means that we need to place some security on our pages, but what is the best way to go about this? My guess is that the existing ASP.NET Membership is overkill, but this feature of ASP.NET does give us some nice tools to control access, and store profile information. Has anyone else used the ASP.NET Membership model, and associated it with a Facebook user? If so, what is your experiences, and do you advise it? Is there a better way?
  • Next we want to search for and view recipes. In this case we need users to be able to locate a recipe (easy enough) and then view that recipe (easy enough) and the Facebook user that submitted it and what network they belong to. The questions that get raised here are:
    • Do we store the Facebook user's details in our own data model, and load them from there, or do we go back to the API for that data each time? The benefit of storing them in our application is that we get a speed boost in not having to call the API again. The drawback is that the data might be out of date. The middle ground is that whenever a use logs in, we go back to the API, and update that members information with the Facebook users profile? Does this sound like the best way forward?
    • We also want to get the user's network(s). This appears to be a collection of Affiliations, hence Collection<Network>. Now we can write a query against our own data to get the most busy networks submitting recipes. Again, for speed benefits, we can save the user's network(s) in a table of our own. Again, is this the right way to do this?

In Conclusion

This discussion is really a brain dump, but I welcome the input from other developers who are looking to build scalable and effective applications for Facebook. I'm a big fan of the MVP Pattern and the use of .netTiers I find they they work excellently in .NET, and really make you consider what you are doing and why. I also gives you extremely tight code that is less prone to bugs. My plan is to integrate both into my Facebook application, using the starterkit as a basis.

One final point is that the application I'm planned on building will be monetized. Now I know there are rumours that Facebook is already beta testing monetization schemes with selected NDA'ed application developers, but I can't seem to find a related release schedule or roadmap. Does anyone know about this? My other option would seem to be Paypal, but although I am familiar with the Paypal API (oh the pain), I'm not sure of the impact within the IFRAME environment. Has anyone else tried to integrate a Facebook application with Facebook, and if so, what was your experiences, and would you advise it? Let's face it, micropayments are still a bitch on the web, and there isn't really a good way at present to do this. I am looking forward to find out how Facebook apply the payment model.