Node.js seems to be getting a lot of column inches in the nerd blogs right now, and with a little bit of homework it's not hard to see why.
What would be good to know before diving into learning node? I assume Javascript, but any other technologies or concepts that would help? What would I need to know to go from local testing to production server?
If you're building a vanilla request/response web application, the basics would be:
The http server example is so common in the node world because unlike another web language such as php, your node application is not living 'inside' an apache web server or the like. You are actually creating a working web server that will return responses based on requests. Its a much different way of organizing a program than the typical "stick your html/php/whatever files in the web root of apache" and go. A strength of node is that it takes something like creating a web/tcp/udp/cli server trivializes a lot of the nasty hard parts like thread pools, event loops, locks, etc.
Because you're going to have to deal with these things in a more manual fashion (at least until you either write a module or choose a module to deal with it). Many candidates I phone interview can't define for me the internal workings of how a typical language handles their session store. They just know they stick value X in variable Y and its available for the duration of the session. In reality, there's a cookie that gets set that references a file/database/whatever store somewhere by session id. In node, you pull these values off the http headers yourself (or a module does it for you) and builds on top of the more basic building blocks of http. The same is true of POST and GET data.
That being said, you can use a framework like express - http://expressjs.com/ - to great effect, and it will handle a lot of things for you. However, its still raw enough (which most nodesters prefer imo) that you can get at the internals of the http requests.
Most web applications are going to require some sort of database. Relational databases like mysql are one way to go about this -- many nodesters prefer something like mongodb because it gives them a little more freedom wrt things like schemas + migration, and a little more of a javascript feel (because things look like JSON). Luckily, its not something you have to make a hard and fast choice about because the community has many, many client libraries for the common databases.
As some others have mentioned, this is something that can blow your mind to a certain extent. In many other languages, unless you're using a specific non-blocking framework like twisted in python, or eventmachine in ruby, you're writing code that is synchronous in almost all cases. That means when you're asking your database for information, you're doing it like this:
result = query("SELECT * FROM users");
console.log(results);
console.log("howdy");
Instead, in node (or other frameworks that support callback/event based io), you'll likely write code that looks like:
query("SELECT * FROM users", function(result){
// Do something with your users
console.log(result);
});
console.log("howdy");
In the first example (from the synchronous world) 'howdy' is going to be printed after results. In the second (asynchronous) example, 'howdy' is printed before results.
This can get tricky when you have to do many synchronous operations depend on each other. When you get to this point, its time to look into flow control libraries like https://github.com/caolan/async -- they provide tools for sequencing these operations so your code doesn't look ridiculously nested.
Clearly its a broad question. Personally I think you should just dive in and give it all a whirl. Its actually a good way to learn this stuff.
Node.js is an event-driven system, so a lot of the code you will write will be asynchronous. This means you frequently can't write code like
if( something() )
{
somethingElse();
}
You'll have to do something like
something(function(result){
if(result){
somethingElse();
}
})
(assuming something() is an asynchronous function, e.g. one that doesn't return its result but rather causes a callback (the anonymous function) to be called with its result once it's done)
This is known as the Continuation Passing Style (CPS) and is one of the biggest hurdles you need to get over to use Node.js effectively.
Here's another, more practical piece on CPS: http://matt.might.net/articles/by-example-continuation-passing-style/
If you're building a vanilla request/response web application, the basics would be:
The http server example is so common in the node world because unlike another web language such as php, your node application is not living 'inside' an apache web server or the like. You are actually creating a working web server that will return responses based on requests. Its a much different way of organizing a program than the typical "stick your html/php/whatever files in the web root of apache" and go. A strength of node is that it takes something like creating a web/tcp/udp/cli server trivializes a lot of the nasty hard parts like thread pools, event loops, locks, etc.
Because you're going to have to deal with these things in a more manual fashion (at least until you either write a module or choose a module to deal with it). Many candidates I phone interview can't define for me the internal workings of how a typical language handles their session store. They just know they stick value X in variable Y and its available for the duration of the session. In reality, there's a cookie that gets set that references a file/database/whatever store somewhere by session id. In node, you pull these values off the http headers yourself (or a module does it for you) and builds on top of the more basic building blocks of http. The same is true of POST and GET data.
That being said, you can use a framework like express - http://expressjs.com/ - to great effect, and it will handle a lot of things for you. However, its still raw enough (which most nodesters prefer imo) that you can get at the internals of the http requests.
Most web applications are going to require some sort of database. Relational databases like mysql are one way to go about this -- many nodesters prefer something like mongodb because it gives them a little more freedom wrt things like schemas + migration, and a little more of a javascript feel (because things look like JSON). Luckily, its not something you have to make a hard and fast choice about because the community has many, many client libraries for the common databases.
As some others have mentioned, this is something that can blow your mind to a certain extent. In many other languages, unless you're using a specific non-blocking framework like twisted in python, or eventmachine in ruby, you're writing code that is synchronous in almost all cases. That means when you're asking your database for information, you're doing it like this:
result = query("SELECT * FROM users");
console.log(results);
console.log("howdy");
Instead, in node (or other frameworks that support callback/event based io), you'll likely write code that looks like:
query("SELECT * FROM users", function(result){
// Do something with your users
console.log(result);
});
console.log("howdy");
In the first example (from the synchronous world) 'howdy' is going to be printed after results. In the second (asynchronous) example, 'howdy' is printed before results.
This can get tricky when you have to do many synchronous operations depend on each other. When you get to this point, its time to look into flow control libraries like https://github.com/caolan/async -- they provide tools for sequencing these operations so your code doesn't look ridiculously nested.
Clearly its a broad question. Personally I think you should just dive in and give it all a whirl. Its actually a good way to learn this stuff.
Well, since node.js elevates JavaScript to let you write full scale server applications, you will probably want to be familiar with object oriented techniques:
This will let you organize your code :-)
Obviously (as you already said) JavaScript as a language. I recommend Eloquent Javascript for a great guide to JavaScript.
© 2022 - 2024 — McMap. All rights reserved.