24

Please tell me if:

  • Node.js will make our site faster!
  • Node.js will consume fewer server resources, we can save money!
  • Node.js will make us more productive!
  • Node.js means we can share client and server side JavaScript code.

To clarify, we're rewriting a frontend server, which will talk to our existing Ruby on Rails application as an API. Meanwhile, we'll refactor our Ruby on Rails application into services.

More details on the existing architecture:

  • Memcached for HTML partials caching
  • Redis for session, and some structured data caching
  • MySQL single master, multiple slaves
    • There's one large table that accepts a lot of writes (imagine a poll)
    • Otherwise mostly reads.
  • MongoDB for some metadata
  • Ruby on Rails 3.0
  • nginx and Unicorn
Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
user88487
  • 257
  • 1
  • 2
  • 5
  • 33
    sheesh, all these hipster languages. A well written php application will scale easily, the traditional tools work, don't let those hipsters tell you otherwise. – Darknight Apr 17 '13 at 08:54
  • Sharing your research helps everyone. Tell us what you've tried and why it didn’t meet your needs. This demonstrates that you’ve taken the time to try to help yourself, it saves us from reiterating obvious answers, and most of all it helps you get a more specific and relevant answer. Also see [ask] – gnat Apr 17 '13 at 09:15
  • 1
    "The test of all knowledge is experiment." Without knowing any details of your application, it's impossible to do more than conjecture whether it would be faster, cheaper, or better after a particular change. If my random choice of answer is wrong, your business suffers, I merely get a down vote. –  Apr 17 '13 at 09:20
  • 4
    If rewrites are being considered, you could also consider moving your front-end to client-side javascript, which means you wouldn't have a dynamic front-end server anymore, just static files. – Joeri Sebrechts Apr 17 '13 at 10:06
  • 5
    The question should be more along the lines of "Will the improvements save enough money to the business to make it worthwhile?" It might save money over 5 years but rewriting is expensive and time-consuming - unless your code is a horrible horrible mess I think your managers are being mad – Mikey C Apr 17 '13 at 09:48
  • 11
    @Darknight bear in mind that at one point PHP was the hipster language, and that people showing it could be deployed in successful products promoted its adoption—while the Perl web developers were sniggering at the PHP hipsters. –  Apr 17 '13 at 12:49
  • 9
    I am very surprised no one has brought up the Joel Spolsky article [Things you should never do](http://www.joelonsoftware.com/articles/fog0000000069.html). I'm not saying all rewrites are bad, but I agree with @MikeyC that they should be approached with extreme caution. – Dan Pichelman Apr 17 '13 at 13:30
  • Sounds like your management would find this enlightening: https://www.youtube.com/watch?v=bzkRVzciAZg – BoltClock Apr 17 '13 at 18:07
  • Do you have any performancy issues? What have you done to scale your Rails app? (sorry, I was not able to post a comment) – Marcelo Aug 07 '13 at 19:12
  • @Darknight You're an idiot. Seriously, just an idiot – Kyle Adams Apr 29 '14 at 20:52

2 Answers2

22

Most of the questions you ask are not answerable without context, and are more or less moot given management has already made the choice for you... unless you are asking 'should I quit and find a new job in the face of all this change?'

If your going to tough it out I recommend you read this this post on the topic: How To Survive a Ground-Up Rewrite Without Losing Your Sanity.

I recently started down the path of rewriting a bit of server logic in node.js. The main reason was it is currently written in .NET and we are wanting to migrate away from MS environments down the track.

My experiences so far have been positive, you will have an initial learning curve with all the non-blocking-ness of it but once you get past that it's actually quite fun to code in.. I know, FUN!

It does have a dark side though, every man and his dog who has done some front end development with JavaScript - and that would be every front end developer I hope - gets a little excited when you mention that node.js is 'server side javascript' however that does not mean front end developers will have the experience required to write good server side apps.

For one thing you have consider is that a fatal error will bring down the whole app due to it's non threaded nature, so the stakes are a little higher and you have to explicitly check and catch everything.

For those who have done both front and back - and enjoy both - not having to switch mental contexts from front end to back end languages is a real bonus that I think will ultimately boost productivity in our team down the track.

gnat
  • 21,442
  • 29
  • 112
  • 288
dave.zap
  • 569
  • 2
  • 6
  • "For one thing you have consider is that a fatal error will bring down the whole app due to it's non threaded nature, so the stakes are a little higher and you have to explicitly check and catch everything" - That would be my worry. – tentimes Apr 24 '13 at 07:15
  • Yes, my main point with that statement was that front end only developers are typically not particularly fussy when it comes to exception handling. Come on, it's almost 2017 already ! – dave.zap Dec 19 '16 at 18:13
8

Well, I don't think that rewriting the application was a good idea unless it was performing poorly. To answer your questions:

  1. Node.js is not magic. Your application has huge amount of users, so there is no way to be certain that it will make it faster.

  2. Well, yes, Node.js does in fact consume fewer server resources. So not only can you save money on resources, but you can also do more with the existing ones. This is mostly because of single-threaded nature of Node.js. There is no overhead of additional threads.

  3. Again Node.js is not magic. Having said that, there might be some truth in that. Node.js has a very active community that has created hundreds of modules for every possible task. So it is quite probable that most of the work has been done for you. You just need to fit the pieces together.

  4. Theoretically, yes. Since Node.js is JavaScript, you can share code between the client and server. But I don't know exactly what it is that will be shared. I have not written any piece of code that was reusable on a client. Things that we do on the server usually has nothing to do with the client. More important to me is the lack of context switch. I find it easier to code on both client and server in a single language.

Since Node.js is single-threaded, unless explicitly configured to do so, it can't take advantage of multiple CPUs.

Take a look at the comments too. They provide some good insight into the workings of Node.js.

Peter Mortensen
  • 1,050
  • 2
  • 12
  • 14
Akshat Jiwan Sharma
  • 434
  • 2
  • 5
  • 10
  • 16
    Less resources because of a single thread? What do you think those extra threads would be doing? – Joe Apr 17 '13 at 10:04
  • @Joe as far as I understand they will add up.In node js it is a best practice to dispose off a request as quickly as possible.Either by completing it in one go.Or by resuming it next time.To be honest node js is the only technology that I have made production applications for.So I may not be the best person to compare it with other server side technologies.Which is why I have refrained from making comparisons and just put what I think I know of node js in my answer. – Akshat Jiwan Sharma Apr 17 '13 at 10:14
  • 7
    Yes, a single thread certainly limits resource use, because the server can only do one thing at once on the event loop. It also limits server use, because it can only do one thing at once. It is very important to quote features (single-threaded) and upsides and downsides rather than just upsides. Node.js is suited for some uses but it is a bad idea for others. When your single-threaded node server has capacity issues you might have to add another node instance. Now you have a multi-process server. – Joe Apr 17 '13 at 10:20
  • I see what you mean.I will update the answer shortly(read after some research) – Akshat Jiwan Sharma Apr 17 '13 at 10:23
  • 10
    It's not just about CPUs. The reason *why* it's important to handle every request as quickly as possible (in a single-threaded system with no other concurrency) is because the server cannot service multiple requests at once, so every request has to wait until you've finished handling all of the requests before it. Concurrency, done right, means less waiting. Use of threads is not inherently a performance drain, and single-threadedness (by default or otherwise) is not a performance advantage. – Peter Hosey Apr 17 '13 at 11:53