Nodejs

Cellar is Open Source


Mongoose · Cellar · Nodejs · Endorse.Me

Endorse.me relies heavily on Open Source software, especially the many npm modules maintained by companies like LearnBoost (Mongoose and Express).

In that spirit, we’ve started open-sourcing certain modules of our Endorse.me codebase. The first release is Cellar, a simple short-term single-document storage engine for MongoDB. Built on top of Mongoose, it is intended for caching of simple schemas.

At Endorse.me, we use it in most of our external API’s to cache OAuth tokens or query results. There are more packages coming soon (including a simpler Key-Value implementation of Cellar), and pull requests are welcome!

Child Processes in Node 0.8 'exit' prematurely


Nodejs

Due to a recent change in the API, a lot of existing code based around spawning child processes will break. The change is explained on the Node Github Wiki:

  • the'exit'event is now emitted right after the child process exits. It no longer waits for all stdio pipes to be closed.
  • the'close'event was added that has is emitted after the child has exitedandall the stdio pipes are closed.

Most spawned processes wait for the ‘exit’ event, and should now listen for the 'close’ event. This is a gotcha that burned me with the node.gzip library.

Happy noding!

Airbrake and Forever to keep you happy


Nodejs · Airbrake · Nodejitsu

When developing with Node.js, you’ll notice that, unlike in PHP, if you encounter a really nasty unhandled exception or error, the entire application crashes, instead of just that particular request. While that can be helpful during development, it isn’t ideal to show the Heroku error page to your users in production.

Airbrake (formerly HopToad) is available as a Heroku add-on, and along with the node-airbrake module (thanks felixge!), sending yourself emails with a stack trace when the server crashes is stupid easy.

While that makes your response time to crashes much better, it doesn’t do anything to keep your server available until you manually restart the Heroku process. That’s where Forever comes in, an excellent module from Nodejitsu that will automatically restart your server when it goes down.

Obviously restarting your borked server over and over isn’t a permanent solution, but it allows your server to stay available for the rest of your users even if one of them finds an obscure bug, and gives you a bit more time to find the source of the issue.

Just add a file (mine’s called forever.js) that starts your server with forever, and notifies Airbrake when the server is actually down.

https://gist.github.com/3177501

That should let you sleep a little bit easier!

On the Bleeding Edge of Node.js


Javascript · Mongoose · Development · Nodejs · Bcrypt

Developing with new tools is a lot of fun. They’re usually new because they allow you to do something that you couldn’t before, or in an environment that you couldn’t before. 

Node.js is like that. And while a lot of people complain that it is overhyped (and it is, to some extent), it’s just fun to work with. JavaScript can be a good language, and playing with it on the server is something new, and pretty cool. The fact that I can use the exact same validation expression on both sides increases my happiness as a developer.

However, Node is very young, and very immature. There are tons of modules out there, and more coming every day, but the fact is that you will encounter situations that no one else has encountered before (or at least documented). Coming from Rails and PHP, that’s quite the change of pace.

For starters, how do you store passwords securely in a database? Well, you use bcrypt of course! And there is, in fact, a bcrypt module for Node that is excellent…if you’re not using Windows. One of our developers was using a Windows box, and despite trying to figure out how to get it to build for about a day and half, it just wasn’t meant to be. At some point, it’s faster to boot up a Linux VM than to embody the definition of insanity.

Last I checked, the issue was still being actively worked, with an update from the bcrypt author as of about two weeks ago. The community is there, the ecosystem is just young.

But it’s not just Windows. We work with MongoDB for storage, and on Node, you can’t do better than Mongoose. But as I said, it’s young. So the findAndModify behavior wasn’t available in Mongoose. Taking a closer look at the source on GitHub, I found that the edge version of Mongoose did support findAndModify (in the form of findOneAndUpdate for all you Mongoose users). So I did what any overconfident dev might do: I switched to edge in order to take advantage of the new feature.

Unfortunately, there is a reason that it is not a complete release. While findOneAndUpdate works, there was at least one very nasty bug that I encountered in the Mongoose source. That, and the changes to functionality make certain design patterns much more attractive (namely, passing a Mongoose document as the update argument) that aren’t currently supported in Mongoose.[1]

 And these are just the issues I’ve found. And I’ve barely scratched the surface of what Node can do.

But that’s a good thing. That’s what makes it fun. Everything has pro’s and con’s, and to me, the pro’s of what Node can do, and what I see for the future of Node are well worth some time spent here and there digging into the source code of a newer module.

After all, some people find debugging fun.

[1] I’m still working adding tests to my pull requests to get both of these complaints addressed upstream.

My first real product launch: Sweat, tears, and viral growth


Startups · Nodejs · Launch

3 weeks ago yesterday, I did my first real product launch. I’ve shipped apps before, but I’ve never done developed with a team, and I’ve never tried so hard to get support drummed up beforehand.

This time I did. I spent the 6ish weeks prior to launch developing a social web application in NodeJS with 2 other developers, a designer, and a business guy. We set a launch date ahead of time, and had a promotional team on the ground in our target market pushing people to our early signup page. We got great press, driving even more traffic. We had more people sign up early than I have ever had use one of my applications before, and this was the first time I’ve ever developed in NodeJS. It was exciting.

We planned a soft-launch the day before we were to send out emails to all of the early signups, to be able to start testing the product at some scale before it got out of control. Sunday at 4pm was our soft-launch, and Monday morning was the “real” launch.

One of the developers, the stronger NodeJS and mongoDB guy, had his sister’s wedding the weekend of launch, leaving me and our HTML dev to handle things during launch. Needless to say, we left way too much until the last minute, and the night before our soft-launch I was up until 5am trying to make all of our last-minute changes. The day of the soft-launch was dedicated to moving everything over to the production database and fixing the bugs that popped up during all those last minute changes I had made.

Of course, we ran into difficulties moving the database over, which consumed the better part of our morning prep (who knew that forgetting to drop old indices would cause the entire site to crash, but only on the second access?). Heading into the afternoon, everything on the site seemed to be crashing constantly, and I was living only on several cups of coffee.

Then at 3:30, I had fixed it. Nothing was breaking. Just in time for our 4pm launch. Our business guy was introducing the product to the 4pm soft-launch crowd of around 40 when I saw a horrible message scroll over the logs H10 (App Crashed). I gave him the kill sign, which he apparently didn’t understand, and he tried to log in to the app on the big screen. Everyone in the room started to chuckle when they saw Heroku’s “Application Crashed” screen.

I raced to fix the issue, which I don’t even remember now, and we finally got things underway. The next 3 hours I hardly remember, mostly because I was staring at the logs fly by, waiting for the app to crash so that the other dev could restart the server while I tried to quickly trace and patch the issue. I was so heads-down that a friend of mine didn’t even see me at the launch at all (see below).

The people at our soft-launch were very kind for their patience with our shaky product, and told us immediately of any issues they saw. That also meant that the moment an “App Crashed” message scrolled over the logs, the entire room filled with a chorus of users saying “crash!”. Most of it was property checking null or undefined variables, stuff that should have been caught much earlier.

Some of them were a little more complex, revolving around the data looking differently than we expected. For those of you who don’t know, NodeJS doesn’t play nice when you send two responses to the client. Turns out, looping through an array or object and triggering a res.render or res.send when certain conditions are met is a great way to crash the server if the data isn’t exactly what you expect.

The viral growth was much stronger than we anticipated, and our userbase grew from 40 to 500 in the next 6 hours[1]. Our business guy was ecstatic. My heart pounded seeing the logs scroll by faster and faster, but that made it even harder to watch for crashes and other obscure errors as they happened. I spent the 8 hours after launch fixing things, some of them much more obscure than others (Logging in didn’t work when you didn’t have a gender listed on Facebook, for one).

Launching was one of the most exciting things I’ve done, and also one of the most stressful. I didn’t eat until 9pm that night (Chipotle FTW), but hardly felt hungry all day. I must have sweated out a gallon of water, and I probably took a year off of my life. But it was awesome. To see people use something you’ve worked hard on feels great.

I only got a few hours of sleep that weekend, and spent the entire time working, and it was still one of the most rewarding and refreshing weekends I’ve had.

Lessons learned (most of I already knew but that didn’t stop me from making the mistakes anyway) :

  1. Don’t make changes the day before you launch.

  2. Test, test, test.

  3. The data will not be what you expect it to be.

  4. Calls to the database and external API’s WILL fail. Prepare for it.

  5. Install airbrake BEFORE launching

  6. Set your expectations low (in user numbers), prepare yourself for the worst (out of control growth).

[1]