How do I get started with Node.js(stackoverflow.com)
stackoverflow.com
How do I get started with Node.js
http://stackoverflow.com/questions/2353818/how-do-i-get-started-with-node-js
12 comments
I cannot say enough about the express module. It brings a simple, yet powerful framework for Web and API development. If you are doing any serious API or Web delivery using Node, you will, at the least, be evaluating express.
Seconded. Express is incredible and it's a refreshing take on anything you seen before regarding web frameworks. People saying that it's similar to Sinatra, yes maybe but the strengths lie in the details: i.e. Express" error messages are so aesthetically pleasant, this just a minor thing but this make you happy all the time when working with Express and every other framework feels a step back now. And Node and Express have a rich ecosystem of stand alone modules—they are not designed for one-does-it-all framework.
Paired with Node and its modularity Express it really an eye opener Sinatra never was.
Paired with Node and its modularity Express it really an eye opener Sinatra never was.
i'm curious, why do you recommend the mongo native driver instead of mongoose?
Mongoose is great and should be also checked out.
To get this paradigm shift and the entire experience with Node, NoSQL and especially Node in combination with Mongo the Native Driver is essential:
Mongoose is great and basically an ORM (or they call it ODM, Object Document Mapper) which forces you for good reasons to do a little more preparations like doing a scheme and so on. Point is that's highly recommended as migrations are with SQL counterparts but the point is for the 90% of the projects you start you do not know:
- Will you ever finish the project?
- Will the project ever be deployed?
- Will you ever get heavy traffic and traction?
Often especially with private side projects you just play around and try. Client projects most of the times never reach web scale (and if they reach refactoring and optimizing is easy). Then, most important is is just to get started and the Native Driver is then the best choice because it totally rewires your brain. No scheme, just start. Want another field? Just save another key to this document (=record). Want a join to give users multiple options in a field? Just use an array. Want to save pictures in the DB and not in the filesystem with creating some file organization script, just put them in Mongo with GridFS too (which is fast btw). Let's not forget that Mongos JS interface and JSON data structure are very close to JS and do not feel low level, so native driver isn\t a low lewel driver, it basically provides the original Mongo JS interface which is very convenient and not low lewel at all. You don't have validations but as soon as you need them switch to Mongoose or write them yourself.
To get a proper db model and architecture it's definitely better to a design nice relational data model, use SQL, do migrations and if performance required, put some NoSQL or Redis in between (or whatever). BUT: this is all work and even with Rails where migrations are kind of easy, it is work beforehand and you have to plan a godd structure. This often prevents you just from starting and with the native driver you just start and in ridiculously many cases a plain document orientated data model is fully sufficient and even for those which would require rather a RDBMS this can be tweaked. Performance should never be a problem.
Point is: the classic approach with SQL, data models, mapping, ORMs is good but prevents you from just starting, "sketching" you program and getting out of the door. Latter is more fun and gets things done. Maybe later you have to refactor when a project is successful. But this is easier than doing all projects always in a structured and formal manner. And even if you will use Mongoose all the time it is good that you experienced once the Native Driver, that you know this thing exists and using Mongo with its native interface is as easy as using a toy.
To get this paradigm shift and the entire experience with Node, NoSQL and especially Node in combination with Mongo the Native Driver is essential:
Mongoose is great and basically an ORM (or they call it ODM, Object Document Mapper) which forces you for good reasons to do a little more preparations like doing a scheme and so on. Point is that's highly recommended as migrations are with SQL counterparts but the point is for the 90% of the projects you start you do not know:
- Will you ever finish the project?
- Will the project ever be deployed?
- Will you ever get heavy traffic and traction?
Often especially with private side projects you just play around and try. Client projects most of the times never reach web scale (and if they reach refactoring and optimizing is easy). Then, most important is is just to get started and the Native Driver is then the best choice because it totally rewires your brain. No scheme, just start. Want another field? Just save another key to this document (=record). Want a join to give users multiple options in a field? Just use an array. Want to save pictures in the DB and not in the filesystem with creating some file organization script, just put them in Mongo with GridFS too (which is fast btw). Let's not forget that Mongos JS interface and JSON data structure are very close to JS and do not feel low level, so native driver isn\t a low lewel driver, it basically provides the original Mongo JS interface which is very convenient and not low lewel at all. You don't have validations but as soon as you need them switch to Mongoose or write them yourself.
To get a proper db model and architecture it's definitely better to a design nice relational data model, use SQL, do migrations and if performance required, put some NoSQL or Redis in between (or whatever). BUT: this is all work and even with Rails where migrations are kind of easy, it is work beforehand and you have to plan a godd structure. This often prevents you just from starting and with the native driver you just start and in ridiculously many cases a plain document orientated data model is fully sufficient and even for those which would require rather a RDBMS this can be tweaked. Performance should never be a problem.
Point is: the classic approach with SQL, data models, mapping, ORMs is good but prevents you from just starting, "sketching" you program and getting out of the door. Latter is more fun and gets things done. Maybe later you have to refactor when a project is successful. But this is easier than doing all projects always in a structured and formal manner. And even if you will use Mongoose all the time it is good that you experienced once the Native Driver, that you know this thing exists and using Mongo with its native interface is as easy as using a toy.
ok thanks for replying I see your point. We are currently developing a project that hopefully will reach web scale (that is the goal anyway) and we started out with mongoose (without really thinking about it though) because it brings you a lot of nice things such as hooks, validators, setters and getters. Of course from an experimentation point of view, what you said makes a lot of sense given my experience with mongoose.
mongoose is an ORM, so they're not the same thing. mongoose depends on native driver anyway.
I would recommend a hands-on approach as well. There are a lot of articles on the philosophy of events, callbacks, etc., but it will click much faster if you figure out the patterns yourself just trying to write something useful.
Instead of a chat or a todo app, why not create something cool? Try a small game, a remote control app, cloud music player, etc. Node won't slow you down.
Instead of a chat or a todo app, why not create something cool? Try a small game, a remote control app, cloud music player, etc. Node won't slow you down.
Won't slow you down compared to what? Go? Java? Python's async frameworks? Clojure?
It will slow you down at least as much. Then some more if you try to do something non-trivial and discover node's limitations.
It will slow you down at least as much. Then some more if you try to do something non-trivial and discover node's limitations.
You know in our case, we see node as something that is a little lower level and bare bones. That actually sped us up a bit. You get this, and if you want that - npm this.
You can extend to your heart's content with node on functionality - but you start with the bare minimum and build accordingly to your requirements. You aren't overwhelmed - you are presented with a basic set of building blocks, and when you cannot accomplish what you need to with the current set of blocks, you research the modules that meet those specific needs.
Think of it like building your own PHP stack from scratch from the source. Except with more of a dynamic perspective.
For example, standard crypto functions are not available in the base node, but installing the "crypto" module makes them available. Same for mysql, server pooling functions, clustering, and even a decent web/api "framework" (Express). You add as appropriate. you leave out what isn't needed.
Our team runs a huge PHP stack for all our apps, so it is a breath of fresh air to be faced with the notion that we are truly architecting our entire code platform, bottom up, vs just calling a bunch of pre-loaded functions. This also gives you greater visibility of the overall stack that your code is running under.
You can extend to your heart's content with node on functionality - but you start with the bare minimum and build accordingly to your requirements. You aren't overwhelmed - you are presented with a basic set of building blocks, and when you cannot accomplish what you need to with the current set of blocks, you research the modules that meet those specific needs.
Think of it like building your own PHP stack from scratch from the source. Except with more of a dynamic perspective.
For example, standard crypto functions are not available in the base node, but installing the "crypto" module makes them available. Same for mysql, server pooling functions, clustering, and even a decent web/api "framework" (Express). You add as appropriate. you leave out what isn't needed.
Our team runs a huge PHP stack for all our apps, so it is a breath of fresh air to be faced with the notion that we are truly architecting our entire code platform, bottom up, vs just calling a bunch of pre-loaded functions. This also gives you greater visibility of the overall stack that your code is running under.
That's pretty much what I meant. Node is relatively flat, you won't have to learn a framework, most modules are sets of functions. And once you're comfortable with the platform, you find their interfaces very similar, even obvious. Languages like Python and PHP have a lot more variety among libraries that do the same thing. And you will often be faced with heavy objects with specific initialization schemes.
Depends on the type of learner (trial and error, or firstly building a conceptual foundation). I've come to the point that the pressure of problem solving is not enjoyable for most people.
This question demonstrates what I think has gone wrong with StackOverflow. They have such a narrow view of what constitutes their code mission that they are killing off useful posts like this one.
Amazon has a 35% discount on our book "Node.js in Action" (should give you immediate access to the pre-release: we're just finishing up the last few chapters, but most of the book is available online for purchasers).
http://www.amazon.com/Node-js-Action-Mike-Cantelon/dp/161729...
http://www.amazon.com/Node-js-Action-Mike-Cantelon/dp/161729...
Peepcode has a recent two-part Node video tutorial building an app from scratch with Express and Mocha testing. Includes things like authentication and a way to organize your Express project files with Django'esque mini-apps.
https://peepcode.com/products/full-stack-nodejs-i
https://peepcode.com/products/full-stack-nodejs-i
And I must add: don't waste your time with PeepCode's old Node.js screencast[1]. It's really old, and almost everything has changed since then.
[1]: https://peepcode.com/products/nodejs-i (Last update: August 2010: https://peepcode.com/products/nodejs-i/versions*)
[1]: https://peepcode.com/products/nodejs-i (Last update: August 2010: https://peepcode.com/products/nodejs-i/versions*)
Actually i just learned node a few months ago. If you want to ping me personally i can go through it with you step by step since theres a couple of things you have to figure out and its a bit difficult to remember them through a simple comment.
If youre interested leave me a contact email or whatever in reply.
If youre interested leave me a contact email or whatever in reply.
Serious question:
Why should I get started with Node.js?
I've monkeyed around but don't get it. Maybe I just don't encounter a need for it when building websites for clients. Dunno.
Why should I get started with Node.js?
I've monkeyed around but don't get it. Maybe I just don't encounter a need for it when building websites for clients. Dunno.
This post contradicts what is exposed in other manuals : event-driven is not concurrency. It is not clear if threads can interact in the event-drive model, this could be chaotic.
No, you are right, the post needs some clarification there and thanks for the feedback (I am correcting it). The event loop is no real concurrency but Node's child processes and cluster enable real (multithreaded) concurrency. The event loop is a lean instrument enabling asynchrony within a single thread with minimum overhead leading to some kind of concurrency—or something which is non-blocking and feels "concurrent" for Node and its entire ecosystem—and paired with child processes and cluster you have real concurrency.
If you use child processes then interaction between processes (employing different threads) is easy. With cluster you have to setup some communication between nodes.
If you use child processes then interaction between processes (employing different threads) is easy. With cluster you have to setup some communication between nodes.
[deleted]
Surprised that I didn't see a single mention of meteor.js.
Check it out. The way meteor does client/server code-reuse is the archetype of node.js possibilities.
Check it out. The way meteor does client/server code-reuse is the archetype of node.js possibilities.
There are a lot more similar (and more up-to-date) articles on StackOverflow tagged under 'node.js'.
http://stackoverflow.com/questions/tagged/node.js?sort=votes...
If you find a category and then look at votes - you can usually find plenty of information in the top few results.
http://stackoverflow.com/questions/tagged/node.js?sort=votes...
If you find a category and then look at votes - you can usually find plenty of information in the top few results.
That's an awful lot to throw at someone just starting. I'd say follow the install directions at nodejs.org and then do the tutorial at http://www.nodebeginner.org/
If you need a brushup on js, there are a lot of other options for that including the free ebook Eloquent JavaScript.
If you need a brushup on js, there are a lot of other options for that including the free ebook Eloquent JavaScript.
I see that it has been closed as "not constructive". Looks pretty constructive to me!
Just skip Node and go for vert.x, right away.
[deleted]
What worked for me:
1. Watch Ryan Dahl's intro videos to Node—he is doing the best job of explaining how Node is working and what were his thoughts back then. Highly recommended.
2. Instead of reading long tutorials rather give yourself a small task like a mircosite or a chat (the typical Node standard example) and build it. I would start with a plain and simple site. Later you should dive into some packages. Highly recommended are Express, Jade, Stylus for a quick web app. Then deploy the thing to Nodejistu with 'jitsu deploy' (or another Node hoster).
Step 1 takes 1 hours and step 2 takes 1-2 hours and after that you realize the power and ease of Node and the great ecosystem in form of the npm and its modules.
Next steps are getting into more great modules like Socket.io and trying MongoDB with the native driver (then you rethink web development entirely). Node shines also with none web apps (e.g. just pure services), so choose a use case which you are most happy with.