Dan Newcome, blog

I'm bringing cyber back

Meteor, magic and n-tier applications

with 2 comments

I’ve been shouting about how cool Meteor is recently, but as I’ve been using it I’m wondering about a few things. 

 As was pointed out by someone else in a blog post (which I can’t find at the moment), Meteor is essentially allowing us to go back to writing 2-tier applications like we did when client-server applications were de rigueur. For example, a line-of business application that ran on a workstation but connected directly to an Oracle database without any service layer in between.

The immediacy of this programming method was nice in the beginning, but once we had to deal with schemas and business logic, and mixing various versions of application APIs we learned that this is a pretty hairy maintenance issue brewing. The data lasts a long time in an organization, and new applications are generally built on the data/schema over time.

Contrary to the current conventional wisdom database administration is a real issue and not a trivial thing once you have a lot of complex data. Things like NoSQL really do nothing to bail you out here, the reasons for which are fodder for another entire post. Assuming that you believe me that data maintenance and migration is a tough problem and that throwing NoSQL at it probably isn’t going to fix what you want it to fix, what do we do here?

In the past, before we started sticking Web services in all over the place, the next logical step was to create stored procedures that ran in the RDBMS itself. Now we can expose an API over the data, which is consistent with its schema and allows us to abstract somewhat the actual table structure. Some of these things would be views on steroids, and in more complex scenarios we can do mapping to/from legacy schemas.

If you know me, you know that I’ve always had mixed feelings about running code in the database. Databases are complex enough when you consider indexing and various constraints that are defined on the data. Once you have code running there that does things like create temp tables or iterate through cursors (fetching data) you have potential performance problems, that are far more delicate than looking at a single query in a query analyzer. The database is also notoriously hard to distribute (this is actually one place where NoSQL can be a big win, but only if your app is conducive to it.

Ok so that brings us to what I really want to talk about – Meteor.js and things like Socket.IO and Now.js. All of these frameworks are JS frameworks designed to make server push and pubsub style apps easy to do. The difference with Meteor though is that it is designed to abstract the service layer away completely. The database looks like it is local to the client code, and so we are essentially writing what looks like a standalone app with an embedded database from the client’s perspective. 

 This has some huge advantages in terms of rapid development and deployment but by obscuring the layers of the application it makes reusing the database and server-side code very difficult.

When I first looked at Meteor, I thought of it like a realtime Rails. If Rails is any indication, eventually Meteor will be flexible enough to handle pluggable backends via npm modules, support APIs, etc. Only time will tell. For now I’m having a hard time deciding whether I’m going to double down on using it or not.

Advertisements

Written by newcome

June 11, 2012 at 2:56 pm

Posted in Uncategorized

2 Responses

Subscribe to comments with RSS.

  1. I completely agree. I’ve recently been blown away by what meteor seems to be offering. But when I consider how I’d then create a complex web app (whereas I would have previously used Django) I find myself struggling to see a framework capable of handling complex web apps. As you rightly say, the accessibility and need to properly manage models and associated business logic is critical – something that rails and Django do very well. I’m not seeing how this can be achieved in meteor. I’d be very interested to see whether meteor develop things in this area.

    Ben

    June 16, 2012 at 3:25 am

  2. I’ve been working on a similar framework based on Node.js which offers more separation between client and server code, feel free to check it out ( http://ncombo.com ). Meteor is very impressive and they’ve made a lot of big bets – My framework is perhaps a little more conservative.

    Jonathan

    January 14, 2013 at 11:46 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: