Develop Reference

Is Node.js suitable for my project given how I'm using it?

I'm about to start writing an application and I want to include newer technologies to improve my knowledge and gain a skill set.
I'm using mysql to store user data (no choice), Angular.js to display/template content on the dom, and I wanted to use node.js to return results from the database in json format to be used by Angular.js.
My assumption was I could use node.js (along with the node-mysql module and maybe express)to accomplish my database queries that feed into my Angular.js templates.
Additionally, the application will live on a different server than the database itself and may reside in a mobile framework.
Am I way off base when it come to how to use node.js? Am I just using the wrong tool? Am I on the right track?
Any help, explanation, and points in the right direction would be great. Most of the info I've seen are copy/paste from the node.js site/wiki and don't really answer my question.

This is largely an opinion-based question and likely to be closed, but you're not way off base. What you want to do is absolutely (and commonly) done using Node.js.
As a complete aside, you might like to check out Platform-as-a-Service providers such as Heroku.com and Nodejitsu.com; both offer great and easy Node.js hosting and addons (such as NoSQL and RDBMS data stores) which have free tiers.
For that matter, MongoLab and MongoHQ both offer free tiers independent of Heroku, which you could use from your MySQL-only hosting provider if you like.

Can I use node to power a web application on a separate server?

I asked this (voted to be too broad) Question while working my way through a starter book on node. Reading this book, I'm sure I'll learn the answer to this later, but I'd be more comfortable if I knew this up front:
My Question: Can I (efficiently) continue using a usual webhost such as iPage or GoDaddy to host my web application, building and hosting the front end in a simple, traditional manner through an Apache web server, and communicate with a separate Node.js server (my application back-end) via AJAX for queries and other things that I can more efficiently process via Node?
More specifically, would this be a bad programming practice in terms of efficiency and organization? In other words, would it be likely that a large scale commercial application would ever be handled via this method?

Yes, you can separate the front-end of your web application and the APIs that power it. In fact, this is a very common configuration, especially for "large scale commercial applications".
Where you draw the separation line between the two specifically depends on what you are doing, how you're doing it, and what your needs are. Also, in terms of hosting, remember that if you're accessing something server-side across the internet, you're adding extra latency to everything. Consider getting off Go Daddy and using another host that gives you more flexibility, such as a VPS provider.

It's ok. Actually, this is how things shoud be done. You have a backend API on a separate server and lots of apps which are using the API. Just go with Nginx server, check this Apache vs Nginx.

Yes you can use node js as a part of some big application. It depends on wich type of interaction you would like to get. Is it comfortable to you to mix technologies? Then node is pretty good thing to work over web. I've finished a part of big nodejs-ruby-php-c-flash application (my part was nodejs) for very large data mounts. This application have different levels of interaction. Sometimes I use 2 languages at one time to create each part of my application the best for task I'm working on. There is applications that initiate, run and destroy mutiple OS instances. So using of multi environmental application not so hard.

Best practices of building a website using Node.js

This question's answers are a community effort. Edit existing answers to improve this post. It is not currently accepting new answers or interactions.
I was wondering how one would go about developing a website from scratch with Node.js.
I understand how I could possibly do it, but I am interested in the best design practice.
I need this theoretical website to:
Do a lot of AJAX
Be very straightforward
Be relatively small
Connect to... let's say a MySQL server
In PHP, building a pretty small website was very straightforward - I set up PHP on Apache and a MySQL server and then do something like:
includes/db/ which has connect.php for connecting to the db, a file with common db related functions and so on
includes/layout/ which had stuff like footer.php, header.php, and other layout related stuff
includes/users/ to handle user related actions
Then PHP just let you build pages and include these files together to form a website - I could go something like:
<?php
require_once('inclues/users/user_session.php');
require_once('inclues/db/connect.php');
require_once('inclues/design/header.php')
?>
// Other php or html or related content relating to the page
<?php
require_once('inclues/.../footer.php');
?>
I was wondering what might be similar in Node.js - I am looking for a way to accomplish this which is as simple, fast and straightforward as possible.
If the answer is not simple, I would love a book recommendation, I don't mind reading.
I love event based programming, I really love JavaScript's abilities and I'm really excited about Node.js. I want to learn how to develop this sort of stuff with it the right way from the start.

To start with the bad news: As Node.js is a pretty young technique, I think you'll find that the proces of creating a full fledged website and maintaining/operating it will be very different than what you're currently used to.
Josh3736 adds: Once you figure out how Node.js and its various packages (Connect, Express) work, I found that you can develop new sites very quickly.
The rough edges that currently exist in Node.js, combined with the fast pace of its development and all modules involved can complicate things though, and make things less simple, fast and straightforward than you'd like.
Having that out of the way, here's the good news:
The Node Package Manager, NPM has a lot of good tools and frameworks to expand Node.js's bare bones functionality, making it suitable to create a webserver.
Most notably would be the Express Framework which contains almost everything you need to run a webserver (including cookies, sessions and path routing). Additionally Express supports partials, which take care of your header and footer includes.
Express is built on top of Sencha's Connect. Cookies and sessions are actually powered by Connect. Express is what simplifies your routing and handles views/partials. So if you don't need all bells and whistles that come with Express you could just go for Connect instead.
If you like to use templates for these partials, the Jade Template Engine can speed things up for you. Though Josh3736 points out that Jade is slow and whitespace-significant. A more complete overview can be found here, which includes his favourite, doT. (I personally use Node.js for socket.io based applications only, so he's a better source than me when it comes to templating).
You can connect to MySQL from Node.js using the db-mysql module, but if you don't need that because you're accessing data connected to an already present system, I'd advise to use a more... 'modern' approach, which is to use a NoSQL database as most Node.js projects seem to do. MongoDB via Mongoose is the popular way to go.
Or if it's just storing objects you're interested in, just go for Redis instead (which you're probably going to need at some point anyway).
Once your website is complete, you'll have to deploy it and make sure it keeps running. There are many ways to do so, like using built-in cluster support or use the more feature-friendly forever npm module. See this SO question of mine for more information.
Conclusion:
What I'm trying to get at is this:
Asking what the best practice for building a website in Node.js is, is about the same as asking what the best way to build a website in PHP is: 100 developers will give you 100 different answers.
NPM is blessed with a variety of excellent frameworks that greatly simplify a lot of tasks involved, but it's all based on preference which one is the way to go really.
As I've said, Node.js is still a pretty young technique, so none of the frameworks or additional tools have emerged as 'defacto standard' yet; for most things you're trying to do there are probably various alternatives, and expect your code to break when using most of them during updates, because development of Node.js itself and most modules is fast paced. You'll have to keep up.
Putting it all together:
As I've said, my main production use for Node.js is to be able to use socket.io, so I don't have any good production examples present (And as I'm about to leave on a well-deserved vacation I don't have the time to put one together either). There are some good examples though:
Setup and deployment using Express and Jade
A very complete blog example using Express, Jade and MongoDB
Combining Restify (an extension of Express), Backbone.js and Mongoose
Again, the way to go (and subsequently the example to follow) depends greatly on your ultimate goals and the techniques chosen, but luckily there are plenty of resources available for all of the choices available. Most modules use well documented GitHub repositories and include examples in combination with the most popular modules (See the /examples/ dir that seems to be present in most repositories).
(thanks to Josh3736 for rectifying my errors.)

Where to store design documents for CouchDB?

I'm new to CouchDB and I wonder how experienced CouchDB handles the large amount of design documents.
My questions:
Where do you store design documents: In CouchDB with Futon's "save" or on harddrive then uploading it through the HTTP API?
If you are uploading them, how do you do it? You create custom queries or are you using any framework?
I'm using node.js, are there good libraries/frameworks that I could use to ease the CouchDB development?
Please share your experiences!

1) Since the whole of CouchDB works through a REST API, all Futon is doing really is working through the REST interface. Basically, you will always load it through the HTTP API. It's a matter of choice of which tool you will do it with, in which the tool abstracts the process for you. At the end of the day, all a design document is, is another type of document.
2) Personally, since I am coding for it in python, I use the couchdbkit framework, which has auto document loading on it. I am sure there is something similar for node.js. I am unable to answer though.
3) Maybe node-couchdb, although it seems to be no longer maintained. There is alot of material on the internet, just google it!

CouchApp is the best tool for managing/uploading your design docs. Its main purpose is for pure Couch apps but you dont have to use that aspect, it makes design doc managing a breeze (couchapp push).

CouchDB is JSON over HTTP, both things Node does more or less natively. I've found the npm module Nano to work fairly well.
As far as CouchApp goes, there's a couchapp for node.

Is CouchDB an example of Server Side Javascript?

I looking at using Javascript server side and took a look at persevere/pintura but for a novice like me, I need more documentation and tutorials and CouchDB seems to have a lot of that but is it used as a server side js tool?
Kind Regards

Yes (seconding what #Pointy said above). The JavaScript in CouchDB does run server-side. :)
Beyond that, though, JavaScript in CouchDB can do far more than just map/reduce queries. It's also used for document validation, update handling (for processing XML POSTed to CouchDB for example), as well as HTML or other markup output from either a single JSON document (using _show) or from the results of a map/reduce query (using _list).
CouchDB does not, however, offer filesystem access or TCP/IP listeners as Node.js does. Right now, the JavaScript is focused on the "shipping and handling" for the database contents (things like validation, formatting, and querying).
If you're interested in looking into options for handling things that CouchDB doesn't do "internally" (image processing, sending e-mails, etc), you might checkout my reply about CouchApp architecture options.
CouchApp's are definitely a viable option for web apps. Coupling those with replication, it's hard to beat.

http://nodejs.org/ is a great example for server-side javascript. If you don't want to write your complete webapp on NodeJS you can trigger it via the node command.

CouchDB is a database with an interresting feature, it allows you to interact via a RestFull api making it ideally suited to access over the web, either in javascript or other client environments. If you are looking for a server-side javascript development environment, try Servoy. It allows full featured server-side application development in javascript including easy database access to all major databases.

Short Answer: Yes.
Longer Answer:
There is a Javascript Engine shipped with CouchDB, which is SpiderMonkey
(the very first engine, open source, written by Brendan Eich, creator of javascript)
CouchDB's View function is JavaScript function running server side that acts as the Map half of a map/reduce operation to construct view.
Then there is client side javascript API, which can be used to communicate with the REST layer to fetch/update documents, which is also where jQuery is used by CouchDB.
More on CouchDB's both server-side & client side javascript capability:
The default engine is capable of doing many features, while package availability is limited compared to Node.js. Kan.so can be considered "NPM for CouchDB, where some packages are server side.
For example, there are frameworks like duality that try to make use of both server side & client side javascript capability to reuse code for rendering with couchDB.
More on the engine:
(The selection of spider Monkey over v8 is because for couchDB's use case the map reduce is not v8 designed for. Also include packaging, multi-threading and also historical reason v8 did not exist that time when spiderMoney is chosen) see [the mailing list] and tweet2
There is even project to port the whole CouchDB to Node.js (i.e. instead of Erlang), Chesterfield
I am glad if someone can add how Erlang talk with the javscript engine.
Thanks for everyone's answer, this is an important thing to make clear for people like me messing up couchDB with some Node.js packages

No, CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. CouchDB also offers incremental replication with bi-directional conflict detection and resolution.
http://couchdb.apache.org/
CommonJS can be used for server side JavaScript, see here: http://www.commonjs.org/
NodeJS is another: http://nodejs.org/