node.js development on windows

i’m not much of a windows guy anymore, but was asked to make an install script for developers at work who wanted to write node.js code on windows. the problem with node.js development on windows is not so much about node.js itself, but the limitations of the basic design of the language and its solution. with node.js and its event loop-based architecture, it doesn’t excel at computationally intensive code, so its solution is to compile native libraries and use those to get the performance needed.

this solution is quite viable, but this also requires you to be able to compile these extensions. this is where there are a few problems. trying to get a C compiler on a windows box is sort of non-trivial, but what’s worse is that some of the libraries out there aren’t ported to windows and then you are dead in the water.

so if i absolutely had to develop in windows, i’d setup a VM. and if i had to use a VM, i’d use vagrant for headless virtualization management. and if i had to use vagrant, i’d use virtualbox for virtualization because of its built-in integration with vagrant.

but now the problem is there are a bunch of dependencies that need to be installed before you can even start developing on windows: vagrant, virtualbox, some linux OS, node.js in the linux OS and all of the build tools needed for npm installation for the linux VM. now let’s say that you have a team of windows developers and you want to get them setup quickly. how do you do that? well, that was what i was asked to solve and so i decided to make a windows installer that will install all of the dependencies.

it turns out that there is a pretty established solution available: nullsoft scriptable install system. it comes bundled with plenty of examples and though i feel that the scripting language available with NSIS is a little awkward, the documentation and resources available for it make it fairly easy to use.

the trickiest part of the NSIS script was figuring out how to launch an .msi file instead of a standard .exe file. it turns out that you have to invoke it via msiexec.exe.

so great, you can make a windows installer that will install all of your dependencies. spin up a vagrant box, install all of the dependencies in your VM, then package it up and make an installer that will install everything for you. easy! now you will have an automated install of your development environment.

using livereload without the browser plugin

livereload is a little project that dramatically changes a front end developer’s life. it watches the filesystem for changes and will tell the browser to reload the page if it detects changes on the filesystem.

the idea by itself is pretty awesome. the actual implementation of this is a little weird as there appears to be a standalone app and a browser plugin that communicates with each other to detect the file changes and then trigger a browser reload.

but wait, there’s something even cooler! the livereload node module is an implementation of the livereload server in node.js. you can hook this into your node application and then you won’t need a separate app to monitor for file changes in your codebase. but still, there is some friction here because you still need that browser plugin so that the livereload server can trigger a browser reload.

but if you look at what the plugin does, all it does is inject some javascript on the page to call the livereload server, load up a javascript file, and initiate the websocket connection to listen for triggers. it turns out that you can simply add that script call to your page and then you won’t need the browser plugin at all.

it is technically documented but buried pretty deep in the knowledge base.

livereload is a separate server running in your app, so you just need to stick the code somewhere after your main server has been initiated, i put it at the buttom of my server.js file.

livereload accepts a parameter “exts” which tells it which file extensions to watch. you can add as many server.watch() paths as you want for directories to watch.

then you just need to add this snippet to the bottom of your page template to have the browser connect the livereload server with your app:

and voila, if you make an update to a file in your project, your browser will automatically reload for you.

using passport for facebook authentication

passport and passport-facebook offers very easy facebook authentication integration into your node app. for the most part, it’s very straightforward, but i got tripped up in a few places.

i’m using krakenjs for my express framework so you have to be a little mindful that some of the express setup stuff has been abstracted away from you. because of that, i was puzzled because i didn’t understand why i couldn’t get access to the passport user object once authenticated.

sessions
passport wants to uses sessions. make sure that you enable the express session middleware and make sure you use the middleware before trying to use passport. order matters here. additionally, if you are using cluster, you can’t use in-memory sessions, you’ll have to use something that is globally accessible by all node processes…something like redis can be used via connect-redis.

passport extends express’ req with the isAuthenticated() method
i initially thought that i had to implement and check whether or not the user is authenticated, but passport handles this for you.

you have to implement passport.serializeUser() and passport.deserializeUser()
passport.serializeUser() is the function that will serialize the user info into the session, typically the user ID. at this point, you have access to the Facebook profile object, so you have information like: facebook user ID, username, displayName, etc.

This function is run once at time of authentication to put the authenticated user into the session.

passport.deserializeUser() is the function that will take the user ID from the session then construct the full information of the user and then make this object available in req.user. this function is run on every request to construct the req.user object so make sure that this code is performant. documentation everywhere says that this is where you would query a database to get user information, but it seems like involving a caching layer here would be advised.

setting up SSL for node using express

i’ve been working with node a lot lately and i’m surprised that i haven’t needed to do this sooner, but i finally needed to set up SSL for one of my node apps and it wasn’t hard to do, but there was no one place where all of the steps were documented on how to setup SSL using express. it actually is pretty straightforward and easy.

first you need to create a certificate for SSL. this can be done by using the command line tool: openssl.

once you have the certificate, all you have to do is tell node that you want to use the certificate you made for the SSL requests. what i didn’t know, but is actually very clearly documented in express’ api documentation is that the variable “app” returned by express() is actually a function used as a callback for node’s http to handle requests. so instead of starting up your server via an app.listen() call, you can simply go back to the basics and use node’s http and https APIs to start the server and pass express’ app to it.

if you want the same code to handle both http and https requests, you can simply call http and https’ createServer() method on different ports.

debugging node with trace.gl

i’ve been using trace.gl for a little while now on my code projects and i’ve had a few thoughts. first and foremost, what trace.gl delivers what is promises by giving you a very visual representation of every single line of code executed in real-time. i’ve had hit or miss success with it debugging a non-trivial express-based project. the most common culprit is that trace.gl appears to consume all of the memory available and just dies a horrible death. i’ve had some other minor issues with the browser crashing out on me as well.

so far, my go to debugging method is still using node-inspector, but trace.gl hints at some great potential. i’m trying to use it more and see if i can incorporate it in my debug workflow, but the amount of code that it rips through is impressive and daunting at the same time. still, it’s a steal (well, for commercial software, anyway) at $15 and is definitely worth a look.

nock – the web service mocking node module

I have recently started to develop a node project where I am promised that all of the information that I will need to render a page will be exposed via API calls. This is fantastic because it significantly simplifies my development as it is easy to call a bunch of services and manipulate data.

The problem is that the services that I am promised to develop my project have not been created yet. Worse yet, the delivery of these services look like it may be weeks from now, but I need to start my development on the front end side of things now!

We’re using node to power our web server, specifically the express web framework and so it seemed only natural to be able to mock our web services within node. Ideally, I should be able to swap my mocked services with the real services in a relatively painless fashion (via a configuration parameter, perhaps?)

flatiron’s offering of nock seems like a brilliant idea. What it does is intercept every HTTP request to a given endpoint and returns your mocked response instead. That, alone, makes nock pretty cool. But wait! There’s more!

nock also provides a way to record any http request and then save the response as a nock mocked object. You just turn on the recorder, make your http request, and then you will have all the code necessary to “nock” it out.

That’s AH-MAZ-ING!

node-inspector live editing

What makes node-inspector the coolest thing in the world EVER? One feature that isn’t touted as the coolest thing ever is the ability to live edit running code. That means that once you are in the debugger, you can set breakpoints, step through code, and actually edit the code that is running on the server and it’ll be updated immediately.

What kind of voodoo awesome black magic is this?? This is invaluable for debugging because you do not have to waste your time adding code, restarting your server, and seeing if this works for you. Sure, you lose the features of your IDE and this doesn’t save your changes to the file system, but this is AH-MAZE-ING!

debugging node.js with chrome

When writing node.js applications, one of the more difficult things that hasn’t been highlighted very well is how to debug node.js applications. How does one add a breakpoint? How do you step through code? Isn’t there some way to do this?

Approach 1: If you are an Eclipse kind of a developer
Joyent has documented an approach to use Eclipse and the Google Chrome Developer Tools plugin to add debugging capabilities to your node.js app.

Approach 2: node-inspector
There is an amazing node module called node-inspector which gives a web interface to node’s debugging abilities. It allows you to debug your node app while using the very familiar Google Chrome Developer Tools. This is my preferred method to debug node apps since I live in Sublime Text Editor.

I really like this approach because it’s lightweight for the developer. You run your debugging in a web browser in an interface that is very similar to debugging front end JavaScript code. The learning curve is low and it’s easy to get up and running.

There’s already a fantastic write up on how to do this, so I won’t repeat it here, instead go check out how to debug a nodejs app with chrome dev tools.