That's fine. Did the code become easier to maintain? It's not clear from the article. The "The good" section is relatively weak and the "The not-so-good" has some painful points about memory management and api instability.
It sounds a bit like you guys rewrote it because node.js is hot and you then stuck with the rewrite because of sunk costs. Or am I imagining things?
Thanks for sharing your experiences with us. I'm just asking those questions because I want to learn more about them.
Well, we assumed everyone knew about the good... so yes, we're happy with the rewrite and will probably never go back. Also, a 25% saving in servers for us translate in several thousands of dollars saved monthly. Not negligible :)
Yeah but in your article you said you're not even sure if this is because of node. You made some architectural changes in your code base and hinted that might have been a reason for the speed boost too.
The article might as well be written as "we refactored our code and got a nice speed boost".
Well, again, most of the dependencies we used in Ruby did not see any update in the 3 years we've been using them. We also reported several bugs in those libraries/dependencies which were never fixed. This led us overtime to use our own branch of all the significant dependencies we had (including the MySQL gem for EM, the redis gem... and several other key ones).
Most of node modules are still in active development. As I've stated in the blog post, that's a pro and con, but we estimated that the pro was greater than the con :)