We're running a nodejs+nosql+js-heavy-client project right now. While evaluating any stack component is an important task, it is certainly more so important in this environment.
This guide is OK, but it's insufficient. If you're going to do a technical evaluation of the node/nosql/js-client stack for risk assessment, you're going to need to get much more granular than what this guide offers. This is a fine guide for a project lead, but this is somewhat useless for the system designer.
For example, in reference to "nosql+node+buzzword+bull$#!t", the advice is to use nosql when you "really" know it, otherwise stick with mysql/postgres. While the devil-you-know-vs-devil-you-dont is a fine project mitigation strategy, it's not a very good technical strategy. Maybe the guide's author assumes one would do so, but the nosql/rdbms comparison exercise is not trivial and requires you to do your homework. Understanding and contrasting the finer points of comparing nosql operations vs. relational data stores is much more useful than a blanket comment.
Like I said, it's a fine guide, but it's much more useful for those who aren't necessarily responsible for determining the stack's applicability to a given project.
This guide is OK, but it's insufficient. If you're going to do a technical evaluation of the node/nosql/js-client stack for risk assessment, you're going to need to get much more granular than what this guide offers. This is a fine guide for a project lead, but this is somewhat useless for the system designer.
For example, in reference to "nosql+node+buzzword+bull$#!t", the advice is to use nosql when you "really" know it, otherwise stick with mysql/postgres. While the devil-you-know-vs-devil-you-dont is a fine project mitigation strategy, it's not a very good technical strategy. Maybe the guide's author assumes one would do so, but the nosql/rdbms comparison exercise is not trivial and requires you to do your homework. Understanding and contrasting the finer points of comparing nosql operations vs. relational data stores is much more useful than a blanket comment.
Like I said, it's a fine guide, but it's much more useful for those who aren't necessarily responsible for determining the stack's applicability to a given project.