6 ms·

There is still some confusion for me as to whether it's "production ready." Ryan Dahl said for a long time that it wasn't ready for production, but I haven't he

There is still some confusion for me as to whether it's "production ready." Ryan Dahl said for a long time that it wasn't ready for production, but I haven't heard anything like that recently. In fact, I've heard others proclaim they're using it for larger sites just fine (citing poor SSL support as one of the primary drawbacks). I also remember Ryan saying that the memory management within V8 caused a lot of the bugs they were dealing with. So what's the real status of the project in terms of putting it into production?

chapel 16y ago
I don't speek for Ryan Dahl or the community at large, but from what I can tell hanging out in the IRC room and reading the mail list is that it is ready for production for just about anyone. Now mind you, anything this young isn't going to be perfect, but what systems are? As far as I know the SSL issues are fixed or being patched ASAP, so you should be able to get something up and running and feel fairly secure in it 0.4.0 brings quite a few API changes from 0.2.6, so if you haven't been keeping up, you should really scour the API docs. You can also check out the wiki for a guide on migrating. https://github.com/ry/node/wiki/Migrating-from-v0.2-to-v0.3 https://github.com/ry/node/wiki/Migrating-from-v0.2-to-v0.3
gmac 16y ago
I was all set to start a new project on node.js a couple of months ago, but ended up back on Rails. Not because node.js itself seemed flaky, but because libraries were scarce (e.g. anyone know of a credible ORM?) and, where available, often in alpha. This isn't a criticism: it's inevitable in a young platform, and I'd happily help develop the libraries. But it didn't seem a feasible option for a project that (a) had deadlines and (b) needed features beyond the (impressive) node.js core.
- davej 16y ago
  > anyone know of a credible ORM? Node devs tend to take a different approach to Rails/Django in this regard, there's no single ORM with lots of database backends (ala ActiveRecord). This is probably related to the fact that Node devs tend to use tools like Redis, Mongo and Couch rather than traditional relational databases like MySQL and Postgres which all have similar SQL interfaces. There are some really nice libraries and modeling tools available but they're not database agnostic SQL ORMs, for example recently I've been using Mongoose: http://mongoosejs.com/ http://mongoosejs.com/ I've come from the Django world so I empathise with the "How do I do [insert Django/Rails feature here]?" mindset, but a lot of the time the Django/Rails just doesn't work well Node. Node.js is a single-threaded, event-based, non-blocking server; it really is a totally different paradigm so you have to be prepared to rethink the modus operandi for developing web applications.
  - gmac 16y ago
    Of course, I did think about Redis/Mongo/etc. But the project (a) had deadlines, so I thought I'd go experimental on only half the software stack, (b) seemed very nicely suited to relational data modelling, and (c) allowed me to indulge my infinite love and respect for Postgres (stable! solid! powerful! frugal! fast! free!). Also, I didn't find a lot of help online with how to do this modus operandi rethink. (Again, no whining implied).
mcotton 16y ago
We have been running one of our critical services with node for a couple months now without any problems. It has been excellent to work with and I'm going to do more with it.
antirez 16y ago
It is very hard to define "production ready". I think that one could say that a new version of a software tends to have a lot of bugs. The more work you put into fixing this bugs (assuming you are not adding new code), the more stable it starts to be, and discovery of new bugs is more and more rare. It does not mean the software is bug free, but that the bugs that it contains are either edge cases that is rare to run across, or they manifest very rarely as real world consequences. I guess that what we call stable is just the state where no obvious bugs arise in normal usage and at the same time is pretty rare for the developers to discover, get notified, and fix, new important bugs. It seems like that under this assumptions node.js is stable enough, but what are you doing with it? Maybe it's not going to be "mission critical", but good enough to run production web applications.

chapel 16y ago

I don't speek for Ryan Dahl or the community at large, but from what I can tell hanging out in the IRC room and reading the mail list is that it is ready for production for just about anyone. Now mind you, anything this young isn't going to be perfect, but what systems are? As far as I know the SSL issues are fixed or being patched ASAP, so you should be able to get something up and running and feel fairly secure in it 0.4.0 brings quite a few API changes from 0.2.6, so if you haven't been keeping up, you should really scour the API docs. You can also check out the wiki for a guide on migrating. https://github.com/ry/node/wiki/Migrating-from-v0.2-to-v0.3 https://github.com/ry/node/wiki/Migrating-from-v0.2-to-v0.3

gmac 16y ago

I was all set to start a new project on node.js a couple of months ago, but ended up back on Rails. Not because node.js itself seemed flaky, but because libraries were scarce (e.g. anyone know of a credible ORM?) and, where available, often in alpha. This isn't a criticism: it's inevitable in a young platform, and I'd happily help develop the libraries. But it didn't seem a feasible option for a project that (a) had deadlines and (b) needed features beyond the (impressive) node.js core.

davej 16y ago
> anyone know of a credible ORM? Node devs tend to take a different approach to Rails/Django in this regard, there's no single ORM with lots of database backends (ala ActiveRecord). This is probably related to the fact that Node devs tend to use tools like Redis, Mongo and Couch rather than traditional relational databases like MySQL and Postgres which all have similar SQL interfaces. There are some really nice libraries and modeling tools available but they're not database agnostic SQL ORMs, for example recently I've been using Mongoose: http://mongoosejs.com/ http://mongoosejs.com/ I've come from the Django world so I empathise with the "How do I do [insert Django/Rails feature here]?" mindset, but a lot of the time the Django/Rails just doesn't work well Node. Node.js is a single-threaded, event-based, non-blocking server; it really is a totally different paradigm so you have to be prepared to rethink the modus operandi for developing web applications.
- gmac 16y ago
  Of course, I did think about Redis/Mongo/etc. But the project (a) had deadlines, so I thought I'd go experimental on only half the software stack, (b) seemed very nicely suited to relational data modelling, and (c) allowed me to indulge my infinite love and respect for Postgres (stable! solid! powerful! frugal! fast! free!). Also, I didn't find a lot of help online with how to do this modus operandi rethink. (Again, no whining implied).

mcotton 16y ago

We have been running one of our critical services with node for a couple months now without any problems. It has been excellent to work with and I'm going to do more with it.

antirez 16y ago

It is very hard to define "production ready". I think that one could say that a new version of a software tends to have a lot of bugs. The more work you put into fixing this bugs (assuming you are not adding new code), the more stable it starts to be, and discovery of new bugs is more and more rare. It does not mean the software is bug free, but that the bugs that it contains are either edge cases that is rare to run across, or they manifest very rarely as real world consequences. I guess that what we call stable is just the state where no obvious bugs arise in normal usage and at the same time is pretty rare for the developers to discover, get notified, and fix, new important bugs. It seems like that under this assumptions node.js is stable enough, but what are you doing with it? Maybe it's not going to be "mission critical", but good enough to run production web applications.