Wednesday, 13 July 2011

Back of an Envelope Node.js Framework - Discuss

I had a quiet afternoon today and while "keeping up with recent developments in my field" or as you might call it "wasting my afternoon googling" I got to thinking what I'd like a Node.js MVC framework should or could contain.
How design shouldn't be done


Firstly, I've been playing with Node.js for about three weeks now and I'm impressed, but I can't seem to find a framework that I'm happy with. Backbone looked good, but I wasted three days on it and it was too much like hard work. Similarly Spine which tried to be less complicated, but eventually failed. Finally I really wanted Brunch to work but it was a release behind backbone (which is a major component of it) and I didn't want to get lost in the mismatching documentation (the Backbone release was pretty major).

I have spent a whole lot of time over the last couple of years using python frameworks, especially Flask and I like their approach of starting with a good foundation (in their case Werkzeug) and adding the bits that are still needed. Could that work with Node? I mean writing a basic HTTP server looks pretty straight forward and there are tons of modules to add the other functionality.

So with this possibly naive starting position I grabbed my pen and scribble down some stuff I thought I'd need. Now bear in mind that I haven't much used any of these modules yet, and I pinched several of them from the bits that go to make up Brunch.


I'd appreciate any feedback, suggestions and so on that those more learned than I might care to offer. Few of you will be less learned I imagine.


Here are the transcribed notes with some links:

Server
Routing
Data Store
Models
  • JS Object/JSON?
  • ORM?
Views
    -CSS
    -Templating
Controllers
Middleware
  • how? Express
Other Stuff

If you spot any typos, inaccuracies or just plain lies then please let me know.
Posted by tersecol at 08:09
Labels: , , ,

4 comments:

  1. Anonymous30 July 2011 at 17:01

    My 2c:

    Server:

    Obviously my answer would be zappa, but the updated version is not out yet, and I'm biased, so assuming you're going to use something else... *definitely Express*. Or at least Connect (which is half Express). It's an excellent, dependable and flexible foundation. And at a sane level of abstraction. Pure Node.js will need a stupid amount of boilerplate to do simple things.

    Data store:

    Very superficial analysis here, please take it with a shovel of salt. Couch seems to be great too, but Mongo is clearly the data store of choice in the current Node.js ecosystem, a tangible consequence being Mongoose, the most robust ORM available for Node. Couch doesn't have a query language, only views with map/reduce. It can do all sorts of weird tricks such as serving pages, but I take real web apps over it any day, thank you very much. Of course it depends heavily on your specific needs, in the NoSQL era we don't have a one size fits all solution anymore. There are actually many more popular options to consider such as Redis.

    Model:

    CoffeeScript classes wrapping mongoose models, or whatever else you end up using.

    Views:

    Unless you have to work with HTML coders, definitely Jade (for terseness excellence) or CoffeeKup (for CoffeeScript bliss). Open tag close tag and <%= foo %> are so 1999.

    CSS:

    For my own use the gains in terseness are not usually worth the hassle of an abstraction layer over CSS, but if necessary, I'd pick the excellent Stylus. There also some interesting coffeescript to CSS libs such as coffee-css an ccss, but I deeply hate camelCase.

    ReplyDelete
  2. Anonymous30 July 2011 at 17:02

    Controllers:

    I honestly found your comparison here really bizarre: JS and CS (languages), jQuery (DOM manipulation), Underscore.js (utilities) and Quip (server-side). What did you mean here exactly? Again for my own stupid applications, Express route handlers *are* the controllers. If I had really complicated logic that didn't belong to the model I'd use some plain CoffeeScript classes.

    Middleware:

    Didn't get your meaning here too.

    node-boilerplate:

    Seems very useful for "raw" Express/Socket.IO apps. But I'm not a big fan of generators as a long term solution, I prefer concise interfaces that largely eliminate the need for them. Hopefully zappa will be solid enough to be an option in this paradigm soon.

    stitch:

    Useful, but I think compression is much more important than merging. Haven't used it yet but https://github.com/mape/connect-assetmanager seems interesting.

    Cake:

    Indispensable tool. Works as advertised.

    Backbone/spine:

    I really don't get them. Again probably my applications are too stupid but plain CoffeeScript classes and a clear understanding of what belongs to where in MVC are usually enough to me. Or maybe that's because I come from a flash development background, and I HAD to understand how to properly organize stateful applications a long time ago to preserve my sanity.

    ReplyDelete
  3. tersecol31 July 2011 at 02:24

    I must confess, since I wrote this I have continued to look at what else is around and hence I came across https://github.com/mauricemach/zappa.

    By middleware, I mean "plug-ins" e.g. a database interface or a logging tool. This already seems to be covered in JS with "require".

    Thanks for your input though.

    ReplyDelete
  4. Anonymous31 July 2011 at 07:22

    Sorry, I've been immersed in node for so long that I forgot this meaning of middleware. In node/connect/express parlance, we usually use it to refer to connect "layers" of request handlers we can stack up with `app.use`.

    ReplyDelete

Subscribe to: Post Comments (Atom)