We’re in the early stages of putting together Canary, a continuous integration add-on for Heroku. Naturally, one of the questions that arose in discussions with the team is what to build it with. We’re a Rails shop, but since we’re starting a new internal project, we discussed investing our time into learning something new and exciting like Node.js. Some of us have experience with it, some don’t (myself included), but we were enthusiastic to evaluate it, even if we don’t end up using it for this project. By consensus, we decided to give it a spike and see where it took us.
I’m currently the lead on the project and was tasked with evaluating Node frameworks and figuring out if there was a good OpenAuth solution for connecting to Github, since that will be at the core of the project. Fortunately, finding a solution was fairly straightforward thanks to Node having a bustling community and a lot of active projects.
I decided to start with the excellent Node.js PeepCode screencast to get myself familiar with what Node is capable of and what a project looks like. After viewing, I was still left with a lot of questions about how I’d use Node in my own work, but one clear use case is for sites that require real-time updates. While AJAX has taken the web quite a long way, websockets are the way of the future and open the web up to a whole new way of writing and interacting with websites. With the ideas starting to churn, I installed the latest stable version of Node (0.4.10) from source and continued on my journey.
The next step was to check out some server-side frameworks. I heard Express and Geddy thrown around in our team call, so I started there. Express looked promising from the start. The site is well-documented and has some helpful screencasts, and the Github project page has thousands of followers and shows signs of active development. Comparing that to what I found with Geddy (last release more than a year ago, sparse commits and low follower count on Github), it wasn’t hard to pick a winner.
Installing Express was a snap: npm install express. What’s npm, you ask? Why, it’s the node package manager, which as you’ve probably guessed is analogous to RubyGems. It has a handy one-line install script, so getting that set up was likewise painless. With everything ready to go, I created a new express app, which is well-documented in the official guide.
Now, on to the final goal of our spike—can we get this thing to authenticate with Github? Indeed! A quick search took me to connect-auth which provides out-of-the-box authentication strategies for the major social networking sites as well as plain old HTTP. Since Express is built atop the connect middleware, this plugin should integrate seamlessly.
Of course, to get OpenAuth set up on Github and to share my work with the team, I needed the site to be in a publicly accessible location. Heroku seemed like the obvious answer to my problem, so I followed their Node guide and was up and running in less than 5 minutes. Once I had my URL, I registered the application on Github and all that was left to put the pieces together.
After initially struggling with how to get things to work (possibly due to some noxious fumes in my new apartment, but more likely because I didn’t find any clear documentation walking me through it), I pieced everything together into a basic, functional application that gives you a link, sends you off to Github, and redirects you back. You can check out the code here: https://github.com/ddonahue99/express-github-test
As for our initial question: Will this work for Canary? We’re still not sure, as it’s too early to say and there are a lot of unknowns for a project like this. We have a lot more research ahead of us and I imagine we’ll hold off on that decision until we get closer to writing the implementation. Regardless, we’re excited to have these tools in our arsenal and will be keeping a close eye on them for use in future projects that fit into node’s sweet spot. We’re happy to enter the world of node.js developers!