For the past 6 months I’ve been spending most of my time building a new service called Sled. I’ll write more about Sled in the coming weeks, but for now all you need to know is that Sled is a collaborative list making tool for small groups.
I expect this to change very fast.
The next few posts are a random collection of things I’ve learned after 6 intense months of working with Node.
To Node or not to Node
Late 2010, I was introduced to Node by Peter Griess who has been an early participant in the Node effort. At the time, Peter was leading an effort to integrate Node into the Yahoo! Mail back-end environment. Once I figured the overall architecture for Sled, I met with Peter to discuss platform options. I knew Peter was working with Node but was reluctant to use it given its early state.
After an hour of talking, it was clear that I should be giving Node a closer look. I envisioned the API server as a completely statelessness machine with a a simple document-based data store requirements, serving REST calls using as much of HTTP as possible. Node sounded like a perfect fit. For the first time in over a year, I got excited about doing web development on a new platform. Don’t underestimate being excited about your technology.
Ironically, when I asked Peter if I could count on him to help out he told me he just gave notice… Great! But he assured me that the Node community is pretty awesome and that getting help should not be a problem. He was right.
My main reasons for choosing Node 6 months ago were:
- Team members can easily move between front-end and back-end
- Node is the hottest new platform, making it a good fit for a small project looking to attract talent
Given the early stage of the project, I wasn’t too concerned about performance (which proved to be very high) or stability (which hasn’t been a blocking issue, but see below). I was mostly concerned about libraries and shared experience.
My reasons for choosing Node proved to be right. One exception is code reusability between the back-end and front-end which didn’t really proved to be all that useful. We do a little bit of code reusability, mostly for OAuth 2.0 MAC tokens, but even there, the availability of native cryptographic facilities in Node make the reusable code narrower when moving to the browser.
What I didn’t know 6 months ago, but made me stick with Node:
- The Node community is young which leaves plenty of room to impact core components and library development, and the leads are very open to new ideas and suggestions
- It’s fun. Super fun.
Is it Ready for Prime Time?
Last year, when I told people I am going to use Node for sled.com, I was greeted with a lot of suspicion, warnings, and skepticism. Six months later I can say with confidence that it was the best decision I’ve made on the engineering side of the project. It got us off to such a great start and that despite the early age of the platform.
As a developer, Node has been amazingly stable. Our server experienced one week of instability in over 6 months due to a race condition bug in the Node HTTP client layer. This was easy to patch and was fixed within a week. I was very surprised at just how stable the API server have been. I’ve started with version 0.2.6 and now running on 0.4.9, but experienced little to no disruptions during the transition from 0.2 to 0.4. The Node core team has done a great job at keeping the project stable, even in this very early stage.
What isn’t so great is library stability.
There are days when I can’t believe some of these libraries were ever executed, and this extends to some of the more popular modules. This is very much a work in progress and it requires a high degree of direct involvement in the library development. If you are going to use a module, you should join its mailing list and keep an eye on what is going on. Being part of the community is absolutely required if you are going to use Node.
The Community to the Rescue
Node has one of the best communities I had the pleasure of working with over the past 20 years. Everyone is accessible, friendly, and eager to help. It doesn’t matter if you are an expert or a novice, you are going to get attention and the help you need. This is especially true for the major module leads. Getting a library patch within hours is a pretty common thing and it helps if you work with them to pinpoint the problem.
All things considered, whatever instability Node introduces, the community counters with plenty to spare.
This will be the first in a series of posts about my on-going experience with Node. I hope people new to Node will find it useful. The next post will focus on Node’s non-blocking nature and how it impacts coding style.
Got an interesting Node project going? I’d love to hear about it.
Liked this post? Follow this blog to get more.