Category: mvc

Recently I talked about the new web being that of “building blocks”, or “Lego bricks” setting the foundations for each application or website which encompasses the new internet.  Applications that embrace this new architecture will both embrace the strengths of other applications and technologies through third-party APIs, as well as provide their own in order to share their own strengths in the building block web.  The idea of the Building Block Web being that of empowering each app that uses your technology to now owning the strengths which you, the developer or entrepreneur or business can add to the puzzle.  I’d like to suggest an overall framework for how Building Block Web apps should be built.  The analogy to me makes sense, and builds off of traditional MVC (Model/View/Controller) models.

Building Block Web – the Model

Let’s talk Model.  The Model component of a traditional MVC framework is intended to provide the structure for abstract data access in a sense that your app never actually sees the underlying data architecture, but rather accesses it through a higher-level layer that can provide inheritance and simple methods for getting at that data.  In the Building Block Web we’re seeing this in the form of Cloud data stores and APIs.

Look at Amazon, for instance.  Amazon provides SimpleDB for abstract data access and storage into the cloud and easy retrieval of serialized information.  Amazon has even provided API methods around processing this information with Hadoop and Mapreduce data processing and crunching (although that could arguably be part of the Controller).  Amazon has provided S3 as a simple file storage and retrieval API.

Other traditional services are also providing their own data store APIs.  For instance, Facebook itself has its own Data store API allowing simple storage of meta information about users and things in its database.  The stream itself allows storage of meta-data with each stream item posted via the API, making the need to build traditional local architecture around social workflows less necessary for the developer.  A simple FQL call to Facebook will pull most of the information necessary from the service.

It should be noted that Google also provides similar services.  The spreadsheet API or even Gmail storage API can be used as simple data storage mechanisms.  Or, for more complex data storage and retrieval, AppEngine provides BigTable for that access, along with an entire API centered around storing, compiling, running code, and retrieving data with that code.  The entire AppEngine API itself is somewhat a Model-based Building Block architecture.

It’s interesting to see people try to compare just the Model component of the Building Block web architecture as Web 3.0.  It’s not – it’s only one component.

Building Block Web – the View

For a Building Block Web app or website to embrace all the components of the Building Block Web, it should also embrace a view of some sort.  Remember a View is code that the user interacts with, usually via a browser, and in the Building Block Web participants must provide components (or “blocks”) that sit at the user level reducing the work a developer needs to do to integrate the blocks into their own environment.  Facebook does this very well with its own internal Applications developers can write, as well as Facebook Connect, enabling developers to integrate  the Facebook environment in their own websites and applications outside of Facebook.

Facebook has provided XFBML and an entire Javascript Client library to enable, at the View, for developers to pull pieces of the Facebook architecture into their own websites and apps.  In addition, they have provided a way for developers to host apps right in the Facebook environment itself, giving an even more native approach to Building Block Web development.  Even the Authorization process is taken care of through the View.  Facebook provides simple HTML and Javascript code (or even an XFBML tag if you want to simplify it even further), and in just a few steps (or even copying and pasting through a Wizard), a popup login box will show up, right on your site, with no backend code necessary to log in the user. Facebook handles the authorization process all for you, giving a unique way to use a user’s Facebook credentials for login and authorization into using Facebook’s pieces of the Building Block Web.

Google does similar with OpenSocial.  Through simple Javascript, any OpenSocial-supported container can run OpenSocial apps.  While not quite as simple as Facebook to integrate into your own environment (due to the decentralization of it all, not a bad point for Google), across multiple environments you can write one simple app that uses Google’s standards to share that app, via simple View (aka Browser-side) code one can add to their environment of choice.  Add to that the ability to embed Waves into any environment, and the simplicity of Friend Connect for finding and communicating amongst users on a 3rd-party website, Google contributes to the View of the Building Block web as well.

It should be noted that Twitter has no View to contribute, and I think if they’re trying to compete against Google or Facebook in the new web they may suffer until they do so.

Building Block Web – the Controller

The Controller is the component of an application that controls the entire application.  It makes the calls to the Model, releases the View code to the browser, and is pretty much the brains of the entire application.  Twitter is mostly a Controller-based Building Block web brick.  When you write a Twitter app, you are writing mostly server-side code that accesses the Twitter API through your server.  No View bricks are provided, and there is no Model API at the moment.  Everything is handled at the application level, making the Twitter API a weak set of bricks in this new Web model.

Facebook also provides a Controller set of bricks through its own REST APIs.  As an application developers I can access the API fully on my own backend and the user never sees that part of the process.  I can even make calls on behalf of the user to do things like send notifications or process data (with the user’s previously given permission at the View level).  I can send data and retrieve data from the Model bricks of the Facebook building blocks.

Google also provides a REST layer to its OpenSocial protocols.  MySpace has implemented it, as has Orkut (I believe).  Developers can do similar things with the MySpace and Orkut APIs that they do Facebook, doing all the work behind the scenes.  The Application layer is critical at handling sensitive data that the user may not have access to.  It is a critical component of the Building Block Web.

Comparison of Various Building Block Web Bricks

I’m sure exceptions could be made for all of this, especially considering the entire idea behind the Building Block Web is that you should be able to mix and match.  For instance, I could technically take an Amazon SimpleDB brick and mix it with an iGoogle brick to give full MVC functionality.  However, this table summarizes the capabilities of various players in the space – note that the space is also much larger than this.  These are only some of the larger players:

	Model	View	Controller
Facebook	TRUE	TRUE	TRUE
iGoogle	FALSE	TRUE	TRUE
Twitter	FALSE	FALSE	TRUE
Flickr	FALSE	FALSE	TRUE
MySpace	TRUE	TRUE	TRUE
Orkut	FALSE	TRUE	TRUE
AppEngine	TRUE	FALSE	TRUE
Amazon AWS	TRUE	FALSE	TRUE
Wave	FALSE	TRUE	TRUE
myYahoo	TRUE	TRUE	TRUE

If you’re building for the Building Block Web, you will have the most success finding ways to integrate all three elements of the MVC Building Block Framework.  The idea is to empower users and other businesses in as many ways as possible to fully utilize the strengths you can provide.  If you share graphics (like Flickr or SmugMug for instance), provide not only a REST API to read and post graphics, but a store API for storing meta data about those graphics, as well as a view for enabling developers to create their own wrappers around the graphics. (Note that SmugMug does this, in all 3 layers)

The Building Block Web is about empowering developers and businesses to use a new platform – a platform of platforms, to create, using each brick’s own strengths, their own applications.  Developers and business owners can then take their own strengths and add to that, enabling more bricks to the picture.  My hope is more apps can start to embrace the entire Building Block Web, and not just pieces of it.