The Problem with Full Stack JS Applications

03 Apr 2013

Whilst node.js heralded an era of being able to use a single language for both server and client side development, nobody mentioned the confusion such an approach could cause. It’s inevitable that there’s going to be similarities in code that constructs data on the server and that which presents it on the client. The fact that the two are written in the same language and the structure of them is so tightly coupled can make it easy to lose track of where you are and what you’re doing when knee deep in code.

Having primarily been using a full js stack (express on the server, backbone on the client) for side projects over the last year or so, I’ve certainly found myself tied up in this kind of knot. For example, if I’m looking at event.js, which represents an event on a calendar it could be the server event representation, used as an accessor for a db or a client side backbone model presenting the events attributes as part of a view. Usually (if you’re using a sensible class naming scheme) it is enough to know the file (.php or .js) within which you’re working and if that’s not enough, then the language syntax usually is a dead giveaway for where you are in your codebase. But this isn’t the case when working in one language. My guess is you’re going to have to take a second glance in order to figure out where you are, which isn’t a big issue, but is frustrating.

Currently my apps typically are structured like this:

server.js (Main node/express file)
-lib (Classes for DB Calls)
-node_modules (Node requires)
-public (Client backbone app)
    -css
    -images
    -js
        -lib (Backbone and other dependencies)
        -collections
        -models
        -templates
        -views
-routes (Contains the main express routes)

But I actually think the following is a better approach:

-server
    server.js
    -lib
    -node_modules
    -routes
-client (Renamed from public)
    -css
    -images
    -js
        -lib
        -collections
        -models
        -templates
        -views

At least with the second approach, it is easier to have a clear idea of where to find classes on first opening them. Unfortunately, this doesn’t however solve my problem of moving between server side and client logic and pausing for a moment before realising I am where I need to work. This is a first world problem for which I don’t believe there is a solution.

Tagged javascript, web development,
comments powered by Disqus