4 ms·
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 so
by DoubleCluster 14y ago
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.
- julien 14y agoWell, 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 :)
- octo_t 14y agoHow much development time did this cost though, when you could have been adding new features and improving the user experience?
- julien 14y agoHard to assess exactly, but we were not adding feature and improving the user experience mostly because maintaining the previous code base and evolving it was so costly.
- rartichoke 14y agoYeah 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".