Dan Newcome, blog

I'm bringing cyber back

The future of Web development isn’t MVC, it’s MVM

with 10 comments

When Ruby on Rails hit the Web development world in 2005, it changed everything practically overnight by bringing a pattern rooted in Smalltalk to the Web. I’ve been playing with the recently-released Meteor Web framework and I think that an important and equally momentous shift is taking place in the Web world.

It started with Node.js

More recently, Node.js changed everything again with the idea that the Web could evolve beyond the model where every request/response pair was fully cached on the server before processing was complete. Unfortunately for all of the interesting new possibilities that Node offered it was pretty low-level if you were coming from a mature Web framework.

Node allowed you to write Web services that were difficult or impossible to write previously. Streaming services that made long-running connections and broadcast-style chat apps became trivial to write instead of requiring lots of tweaking and custom server configurations.

However the power that made writing the average chat application easy made doing a Rails-style application tedious. Frameworks like Express came on the scene letting you develop with a more Sinatra-style API, making doing RESTful applications fairly easy. However, I don’t think using Express on its own really harnessed the power of what Node was capable of. Sure, if you needed some server-push goodness it was trivial to drop in Socket.IO, but then you could have used a hybrid solution, using Node for just the server push parts.

Classic MVC on Node – barking up the wrong tree

Those of us interested in building data driven single-page applications noticed that we were building complex object models in Javascript on the client. The classic MVC pattern just didn’t map well to doing this. Libraries like Backbone.js became a popular way of creating a client-side Javascript collection that mapped to a RESTful API on the server, creating a MVVM-style (Model-View-Viewmodel) development model.

At this stage the more observant of us might have noticed that if we were using Node.js on the server, we had the same language running everywhere and were doing a lot of work on the client just to model what we already had on the server in the same language with two impedance mismatches along the way.

Let me explain what I mean about impedance mismatches. When we write an data-centric application we start with some data. That data is going to be stored somehow, probably in a document store or relational database. On the server we have some query language for retrieving what we want. This is the first mismatch, which is commonly handled by an ORM (Object-relational mapper).

The second mismatch is the mapping of the individual data queries to an API. All of the CRUD calls get mapped onto URLs and HTTP verbs in some way that probably loosely resembles a REST API.

Why Meteor is a game-changer

When I first looked at Meteor I was trying to figure out where the server-side controller code was running on one of the sample projects. When I looked at the server code I was surprised that there wasn’t really anything there except a pair of MongoDB collection definitions. Meteor provides an ORM layer that loosely mirrors the Mongo query API. The thing is, this full API is available directly on the client. When we want to query our data store, we can do it transparently from the client-side data models.

Simply put, Meteor does for data what Rails did for template based Web sites. Templating is still an important part of what Meteor provides, but those templates are bound transparently to data collections. Templates re-render implicitly when data changes. This stuff works out of the box by default with no extra configuration, just like that first magic moment when you saw rails do form-based CRUD on a data record with almost no custom code.

So, I’m thinking of what Meteor does as MVM (Model-View-Mapper). There is still a model in my mind, which is essentially a viewmodel since they are created largely to support the bound views. I’m thinking what would have been the controller in an MVC model has actually been replaced by some ORM code that supports what the views need to display the data.

I’m going to be refining my understanding of Meteor during the course of a new project I’m working on, so perhaps my mental model will change from what I’ve described here, so I encourage you to check out Meteor and let me know what you think in the comments.

About these ads

Written by newcome

April 14, 2012 at 2:32 am

Posted in Uncategorized

10 Responses

Subscribe to comments with RSS.

  1. Thanks for giving such a useful information.

    Website Development

    April 26, 2012 at 3:16 am

  2. Great post. Did not tried Meteor yet but this is the second recommendation I find. I will check it out in the near future. MVM seems similar to MVP or RVP, represented in http://blog.nodejitsu.com/scaling-isomorphic-javascript-code Very good ref BTW, with a very good explanation on web applications with the logic client & server side.

    Thanks,
    Alessandro Mascherpa

    almadeweb

    May 9, 2012 at 11:20 am

  3. Hi there, Thanks for giving such a useful information.I like your post very much because it helps me to know about web design and technology. Did not tried Meteor yet but this is the second recommendation I find. I will check it out in the near future.

    mily kristina

    May 14, 2012 at 9:21 pm

  4. It seems out of my mind as these things are always theoretical to me whether MVC is for any language. It may be because of lack of scope of work in such environment. Whatever trend will come that will be keeping on the technology change and new demands.

    varindiamagazine

    July 19, 2012 at 4:26 am

  5. now, I’m more interested to try meteor.

    Lex Bryan

    August 15, 2012 at 4:01 pm

  6. Thanks for this information. I was thinking about the future of Rails and how Rails will compete with this fast growing of Javascript in the server-side.

    I haven’t worked with meteor before but i think it will give another push for javascript server-side frameworks over Ruby On Rails.

    Your words encouraged me a lot to try meteor sooner :)

    Thanks.

    Mohamed Elsaka

    September 7, 2012 at 11:06 pm

  7. [...] only one thing that they could possibly help – by building API-centric websites. That way from the ground up, if they decide on a new language to make things show up in a [...]

  8. Reblogged this on chipsoul web solution and commented:
    application development company

    chipsoul

    April 7, 2013 at 10:45 pm

  9. […] of code that needs to be written for a real-time or collaborative app. As one article put it, Meteor has made MVC obsolete. When leveraging front-end frameworks such as Twitter’s Bootstrap that integrate well with […]

  10. If anyone asked me 6 months ago I’d have said this article was BS. Although I haven’t had a chance to use node.js professionally yet, I have been working with json based APIs serving MongoDB data to AngularJS front-ends for several months now. This has been long enough to convince me that the whole paradigm of what we thing of as web development is about to change. Was getting tired of constructing monster page views on the server side anyway … in case anyone from WordPress/Drupal is reading this?

    Peter Drinnan

    July 30, 2013 at 6:17 pm


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: