I've already written all of my APIs and the entire backend using NodeJs and Postgres. My biggest fear is what happens if it breaks down, as my start up is something akin to say twitter(not really, but thought that's a better example when it comes to stability and a good API), I'm worried if node is good enough to build the next twitter.<p>I'm well versed in Python, and if things go balls up, I can rewrite the entire backend in a weekend in Python. But having used Python before in many other projects and been rather pissed with its overhead of realtime operations, I picked Node as the way to go.<p>But am I right?
If things have gone wrong for people here using NodeJs, where does it happen? Which parts should I be most careful in during the architecture of the project?<p>EDIT:<p>Thanks for the answers till now. To clarify, no, I'm not building the next twitter. I took it as an example to explain a worst case scenario(or best case scenario, the way you look at it). Recently Jeff Atwood wrote about why he choose Ruby, and he made a valid point that isn't the cool language anymore. It has matured, stable and all of that. Considering that I wasn't using Node since it came into existence, I can't comment on its maturity.<p>Most examples in Node available on the web, try to clutter up everything in one file. So, I wanted to know the best practices when it comes building an architecture in node.
We've built the control plane to Rackspace Cloud Monitoring in Node.js, and overall the experience has been positive.<p>A few things to look out for:<p>1. Error handling. In node you can't just wrap your code in a try/catch. And even if you register a listener for uncaught exceptions, you almost certainly have state shared between requests (for example, a database connection pool), which makes trying to handle such exceptions risky. To use node effectively, you need to be very careful to prevent exceptions from being thrown in unexpected locations.<p>2. Code rot. It is a lot less obvious what is idiomatic in Javascript as compared to Python, etc. Its easy to end up with a wide range of styles and patterns, which make maintenance difficult.<p>3. Missed or double callbacks. These are interesting mostly because they are not something you would see in synchronous code, and they can be quite difficult to troubleshoot (especially double callbacks).<p>Mitigating these issues is as much a cultural challenge as it is technical. Lint everything, review code aggressively, and don't merge code that doesn't have tests. Choose libraries carefully (the ecosystem has come a _long_ way in the last few years).<p>All of that being said, these are things you should be doing anyway. Develop a good tech culture, but get your product out and grow your user base. If you become the next Twitter you'll have the resources to undo any mistakes you make now.
Node.js itself is fine.<p>The real problem with node.js is the libraries. Just don't use them.<p>A huge portion of existing libraries is full of hidden bugs, shortcomings, race conditions, edge cases, security issues, unscalable, or unmaintainable (and unmaintained).<p>This is exacerbated by the fact that npm makes it really easy to publish a library.<p>Many small buggy libraries.<p>Core modules are too low level (e.g. http), and you really don't want to use an overlay library.<p>Not to mention that doing something not trivial fully asynchronously is not as fun as it sounds. You will spend a significant time tracking bugs, fixing edge cases, and making your code stable.<p>There is still no way to make async code better in core (no promises); and there are a handful of incompatible promises implementations.<p>Oh, and node.js is not really fine actually. It's not doing everything using asynchronous I/O as you would expect. Node.js uses a thread pool for things like DNS resolution and disk I/O. Only 4 threads by default, for all those things with very different latencies. This means that 4 DNS queries can occupy node.js's 4 hidden worker threads, and block your disk I/O for minutes.
Premature optimisation is the root of all evil. If you're building something that will be as big as Twitter, the programming language will be the least of your problems. Figuring out how to scale all of the connected system horizontally, independently, will be more important than whether you chose Node or C# or Java or Python.
It works for us, but it comes with a lot of issues, some of which are pretty major, although this holds more true in the ecosystem, not always in core.
Problem is see is that no one seems to know how to solve them (it's a callback, no it's node, no it's v8), takes so much time or just plain don't care (socket.io, I'm looking at you), so you're on your own if you encounter something critical.<p>Either case start getting traction, don't over optimize at the start and watch out for memory leaks: there are tiny bits of best practices that you must follow (always consume the response? check. close the request appropriately? check. don't crash the whole node process? check.), some of which not really well documented, that can ruin your day should you get some important press and are not implemented correctly.<p>Take a look at the issue tracker of the libraries you are going to use, check if there's something that can affect you and perhaps contribute back!
I run <a href="http://jsonip.com" rel="nofollow">http://jsonip.com</a>. It's a single node process running on a VPS. It supports more than 10 million requests a day and barely stresses the system. Granted that its a relatively simple app, but it's raw node.js. I can easily scale it in a few simple ways like adding a caching layer and/or load balance a few extra servers. Haven't needed to yet.
Mozilla uses node.js for several parts of their architecture: <a href="https://hacks.mozilla.org/category/a-node-js-holiday-season/" rel="nofollow">https://hacks.mozilla.org/category/a-node-js-holiday-season/</a> (recommended read).<p>It should be stable enough for building a large scale application but maybe not easily for an app as big as Twitter (we are talking about a shit-ton of requests per second). You are not there yet though, are you? :)
I'm not sure how you're defining 'stable' here, but I'll comment on another aspect of your concern.<p>Twitter started with Rails, and at some point decided it was more efficient to do an incremental rewrite on the JVM.<p><pre><code> I can rewrite the entire backend in a weekend in Python.
</code></pre>
I'd bet it took Twitter a bit longer to replace their infrastructure, and they survived just fine.<p>Build in whatever is rapid, for you. At this very moment. Using your resources.<p>Keep things service-oriented, decoupled. It'll be easy to replace things one component at a time, if needed.<p>in summary..<p>I think it's a perfectly cromulent platform to build on in terms of speed and scalability. <i>But</i>, in case you and I are wrong, follow my advice about staying decoupled and it won't hurt as much.
Yes, it is stable enough. BUT, that assumes you know how to write code that will work under various conditions that can and do arise.<p>The main thing that can cause shit to hit the fan is not properly handling errors. I highly suggest using domains, and that when an error occurs, if you can, that you gracefully exit. If not, then all other requests will just abort and that isn't very user friendly.<p>You will also want a way to be notified of errors, so you can stay on top of them and fix them right away. I use winston and have the error level set to email me.<p>If you want to talk in more detail, contact me... address is on my profile.
Whatever you write now would never scale to be Twitter as it is now, there's no point even considering that as you aren't thinking on anything like that scale conceptually. I doubt most developers can. But then writing something that could scale to Twitter scale when you don't have a business or users or revenue would be pointless.<p>Specifically to answer you question, no. Node could work as a thin publishing veneer on a much larger stack but you just don't get what you need from Node.js end-to-end.
If you have enough traction that this is a problem, you can get Ryan Dahl / Joyent / et al to help you.<p>Node's pretty well tested by now for heavy traffic. It's not my personal cup of tea but I imagine that the obvious bugs and performance degradations have all been squished.
If you are not handling every possible error correctly, then you might end up with errors taking down your app with no idea how they were initially caused, so your app can suffer significant downtime without you knowing where to start in terms of fixing it.<p>If things go wrong in python, you'll probably have an easier time identifying it and fixing it due to actual helpful stack traces.<p>You should be very very careful when architecting your project and make sure you understand error handing to a T.
Stable enough? Sure, for a given definition of "enough".<p>The advantages to using Python instead of NodeJS are going to be less about stability and more about maintainability and ecosystem.
We're a full node stack at <a href="http://geeklist.com" rel="nofollow">http://geeklist.com</a> One thing not being mentioned that I'd like to share is the extremely supportive and extraordinarily brilliant community of node.js enthusiasts. This has an intrinsic value that we could never replicate with any other code base. Around the world thousands upon thousands are excited to learn and hack in node. Guys like @mikeal @izs @indutny @dscape @dshaw @substack and so many other great developers in the node community jump in to help everyone else all the time. (Just try reaching out to any of them on twitter and you'll be amazed by the support. Yes we did finally just move up to 0.8.2.3 but running 0.10 caused some hiccups we just dont have the bandwidth to attend to right now so we're waiting just a tad longer. In sum node is great and you'll find developers absolutely love hacking in it which means they are enjoying working on your project/business... Which is priceless.
Node is sitting at the core of the new Viki platform. It's been a pretty flawless part of the stack. We do zero-downtime deploys thanks to the cluster module, which also keeps workers running (I haven't seen an unhandled error take down a worker in a while, but as with most any stack you need to be pretty vigilant about your error handling). At over 3K api requests per second to a single box, we hover at around 0.05 load (our machines range from e3-1230 to dual 2620s, so it's hard to get an exact number). When asked to handle more request, the impact on load is pretty linear.<p>We're also dealing with servers in 4 different locations and some requests need to be proxied to a central location. With a ~300ms round trip from Singapore to Washington, Node's asynchronous nature has been a win when it comes to handling concurrency in the face of backend latency.
This sounds like a Maserati problem <a href="http://www.urbandictionary.com/define.php?term=Maserati%20Problem" rel="nofollow">http://www.urbandictionary.com/define.php?term=Maserati%20Pr...</a>. To answer your question though, many big companies now use Node.js and it is stable enough.
I think that most people that have lots of experience using Node would say that it <i>is</i> stable enough for the most part (that's what I tend to read anyway, big grain of salt with that). Cross-platform compatibility is much, much better than it was in the distant past. It will be the idea and not the technology you choose that will determine whether or not it becomes the 'next Twitter', as long as it is developed soundly. It shouldn't really matter. If you did end up scaling up before the final kinks are worked out of Node.JS and commonly used libraries, then like you say: Just write it in Python over the weekend and see if you can do better.
I think the only problem I have with any of this, is the next Twitter part. If that's what you're thinking, planning around, projecting scaling issues based on, I'd argue you have already ensured failure.
I can't really speak for twitter but we use node.js happily at Soundkeep. It works greate for our use case of streaming audio processing. It has come a long way since it started. Obviously it isn't as mature at Ruby/RoR or Python/Django but not nearly as bloated either. The comparison is weak though since it isn't a framework but more of an environment. A lot of people like to think of it in comparison to the big frameworks though. Node.js is more about smaller libs and modules than any single framework.
I am also working on a similar project using node.js and redis. Please make sure that you are using a perfectly fitting data model. I bet most of the load will come from the database and not from the application servers. We went for an in-memory solution for all timelines and graphs.
Are the people, your developers, the ones that make a platform stable, not technology X.<p>How you manage the database sharding could be more important than if you use nodejs, C, php, cgi + perl...
AirBNB does a lot of node.<p>Much of their stack is node.<p>Like others have said, 'too many users' is a first world problem that many would like to have.