

Node.js: Am I just doing it wrong? - farmdawgnation
http://farmdawgnation.com/blog/2013/10/19/nodejs-am-i-just-doing-it-wrong

======
ricardobeat
All fair points, these are issues faced by almost everyone starting a node
project. Here is a set of good practices that might help:

1\. Use dependency injection moderately. require() calls are cached, and you
can overwrite modules for testing with proxyquire/rewire. If you are using
mongoose, for example, you don't need to throw around a db instance, just
require('mongoose') on each module and access models with
mongoose.model('User').

2\. Separate route definitions from controllers:

    
    
        // tree.js
        exports.getNuts = function (req, res) { ... }
    
        // routes.js
        var tree = require('./controllers/tree.js')
        app.get('/nuts', tree.getNuts)
    

3\. Keep your controllers lean and move logic to your Models or a separate
concerns/lib layer, so you can re-use these methods within the application.

4\. Use a control-flow library like async, queue-async, etc. I wouldn't
recommend promises as a first since they come with their own caveats. Break
down logic into many small methods instead of huge chains.

5\. Absolutely, whenever possible, break out helper methods, abstractions and
common patterns in your code into separate npm modules, with it's own set of
tests. This should be the final fate of everything in the /lib directory, if
you have one. Doing this helps keep your codebase lean and focused, and is a
good opportunity to give back to the community.

A rough suggestion on how to organize that last module.exports using
caolan/async:
[https://gist.github.com/anonymous/7062240](https://gist.github.com/anonymous/7062240)

Finally, it's nice to use a database driver that buffers commands before
connect, so you don't need an async step on app initialization.

~~~
farmdawgnation
Thanks for the helpful tips!

------
hackula1
A couple suggestions:

callback hell -- 1) Define your callback functions instead of passing
anonymous functions everywhere. 2) Use a control flow library like async.
[https://npmjs.org/package/async](https://npmjs.org/package/async) This will
greatly help in complex scenarios and the "waterfall" mode is particularly
useful to accomplish something similar to chaining where values flow through
multiple functions. Callback hell is not really an issue for most people after
looking into these two things.

data manipulation --
[https://npmjs.org/package/lodash](https://npmjs.org/package/lodash) lodash is
a fast functional utility library that makes it much easier to do the everyday
data manipulation tasks. I pretty much assume this will be a dependency
whenever I start a non-trivial project now.

lack of standards -- Most people who really like node.js see this as a feature
not a bug. This definitely drives away many people, but the intention is to
promote as much choice as possible. Node.js people tend to be obsessed with
choice and modularity. This is not meant as "you should think this way too"
type explanation, but just a rough description of how the community is, good
or bad. That being said, there are some standards out there. For example
Felix's style guide is followed pretty well throughout the community (with a
couple notable exceptions such as some of TJ Holowaychuk's stuff)
[http://nodeguide.com/style.html](http://nodeguide.com/style.html).

mocha output -- It appears you have your reporter option set to "spec". This
is a great reporter for visualizing a set of features, but for integration
with something like Jenkins, I would recommend "tap" instead. It is also
pretty trivial to write your own reporter, and then you can get whatever type
of output you want. [https://github.com/visionmedia/mocha/wiki/Third-party-
report...](https://github.com/visionmedia/mocha/wiki/Third-party-reporters)

mocha integration testing -- I agree that the example you showed was more of
an integration test than a unit test. Mocha is not really doing anything to
discourage unit testing though, and I would note that integration tests can be
valuable. If it were me, I would tend to have my unit tests working against
the actual module, instead of an endpoint, which is kind of sloppy.

I hope that helps though :) I know it is often frustrating coming into a new
language ecosystem, especially a "friendly-anarchy" oriented one like node.js.

------
ctvo
I definitely relate with the author. I started my own node.js project last
week.

I have no idea how to organize my Express app, I have no idea what asset
manager to use and yesterday I spent 4 hours just tinkering with my gruntfile
to get concat and copy tasks right so my front-end files get moved to the
proper folders when I'm ready to build. This is all due to my ignorance / lack
of experience, but man, some readily available best practices would be really
helpful.

~~~
declandewet
They're there, you're just not looking hard enough. I commented on the
author's post - what I spoke about might be of use to you too. Also, remember
that as a person with internet access, you're not limited to simply sitting at
home, reading and practicing. Developers of these tools you use make use of
Twitter and IRC and Github specifically so that people who are learning the
ropes can contact them and ask (see: pester) them for help. They don't at all
do it for experience or recognition in the industry ;) Sometimes the best way
to solve a problem is to have a simple conversation with someone a little more
experienced in the field. In fact the author's post is a great example of this
working. He asked for help, posted it to hacker news, I saw it, I helped. :)

------
EasyJoe
See that light gray text on white background? THat means yes, you're doing it
wrong.

I can speak more about node.js once I can read your blog without discomfort.

