Everything you wanted to know about Node.js
Everything you wanted to know about Node.js [Q&A format]
1.What is node.js?
2.What are good ways to learn node.js?
By Dave Stevens
Then it’s just a matter of getting your hands dirty with a few tutorials- howtonode.org and Nettuts have some good ones.
Then finally, an excellent resource is Tom Hughes-Croucher’s “Node: Up and Running” book.
Then just keep practicing by building things with it!
By Ro Rao
Great place for beginners to start: http://nodebeginner.org
By Chris Cinelli
By Brian Moore
Peepcode has a good two part series (I love Peepcode):
3. How do you deploy NodeJS?
I just deployed my first NodeJS app, and it was a bit more of a headache than I had hoped. I used EC2, and Nginx from a tutorial I followed, but then switched to haproxy because I was using socket.io. How do you deploy your NodeJS app? What is an easy set up? What are some of the trade offs?
By Bryant Chou
If you’re looking for an easy way to push a simple node.js app, appfog, dotCloud, heroku, and nodejitsu all offer extremely simple command line tools to help you get running in minutes. They are mostly tied to git, so pushing changes is as simple as checking in your code, then a simple command line command to instruct said 3rd party hosting service to grab the changes and push those live.
At Vungle, we use a series of tools to help us deploy our node code. It’s 100% automated and works like this:
1. Developer checks in code to dev branch (or a hotfix branch)
2. Merges code into master branch
3. teamcity runs our mocha tests
4. Developer clicks a button on the teamcity website to run the deploy job
5. teamcity runs chefs scripts
6. node.js nodes’ chef agents kick in, which: a) pull down whole repo into a new directory, b) runs npm install, c) symlinks current directory to the new directory d) restarts our forever process
This process does not drop any HTTP requests and has proved to be very stable for us. Though it takes some initial investment to get going, the horizontal scalability of our stack is much more elastic now we have this infrastructure in place.
By James Halliday
Don’t write big apps. The more custom code is running in the same process, the harder it gets to reason about existing functionality and iterate on new pieces. Using modules from npm can help avoid the big app trap and you should absolutely use lots of modules, but business logic doesn’t always break down in a way that is easy to modularize in a lib/ directory.
Instead of putting a lot of logic into a single process, consider separating functionality into independent processes that all talk to each other over the network. Luckily, node is really great for writing tiny network servers!
By writing lots of tiny apps, you can:
- independently scale the subsystems. When a subsystem is getting bogged down with requests you can usually just spin up more of them, on the same server or on different servers.
- gracefully fail when one subsystem goes down or crashes all the time.
- keep the entire flow of an app in your head at once. When all your functionality is in the same process it can be very difficult to keep the state from bleeding across all the subcomponents. A network boundary forces you to make state very explicit.
But not so fast! These benefits come with significant costs:
- network communication has much higher latency than in-process messaging
- managing all the processes and keeping track of where they run and in what order they need to start up
- it’s more overhead to set up a network server and you need to worry about serialization and routing messages
- versions can easily get out of sync. When everything is in the same process, all the pieces are written against the same version of the codebase. In a clustered multi-server model it’s much easier for the two pieces to accidentally connect to incompatible versions.
I’ve been working on mitigating some of these costs with projects like
- https://github.com/substack/seaport (cost #2 and #4)
- https://github.com/substack/fleet (cost #2)
- https://github.com/substack/dnode and https://github.com/substack/upnode (cost #3)
For #3 also consider using https://github.com/hookio/hook.io or just a simple http service. Mixing and matching different transports hasn’t been a problem for myself in practice.
If you go the dnode/upnode route and want to also use seaport, check out https://github.com/substack/airport which lets you connect to dnode services by using service semvers instead of hosts and ports as arguments to .connect() and .listen().
At any rate, it’s more important to get something simple up and running quickly so you can iterate on it with the warm fuzzies of a positive reinforcement loop from tiny amounts of incremental progress. Hopefully some of the tools listed here can help you along in that journey and you can incrementally add bits and pieces into your stack where it makes sense to use them.
5. What are some of the bad things about NodeJS?
By Jonathan Ong
My only complaint is error handling. Error handling is a pain because you can’t try/catch errors due to callbacks. Thus, you always have to handle them, otherwise an error is going to be thrown somewhere and your app is going to crash.
Yes, there are things like Domains that help handle them, but they are nevertheless inelegant.
6. Do you think nodejs is the future of web app development?
By Sergey Kovalyov
7. What is the difference between an Apache/nginx server and Node.js one?
By Feross Aboukhadijeh
Apache and Nginx are both HTTP servers. They can serve static files like (.jpg and .html files) or dynamic pages (like a WordPress blog or forum written in a language like PHP or Python). Apache/nginx need to be configured to recognize the URLs that users will be requesting and route them to the right place.
So, for example, with a typical PHP site (like a WordPress blog) you tell Apache that any file that ends with .php should be interpreted as PHP code, so when the user visits “http://myblog.com/tag.php?q=mytag”, for example, Apache will launch the PHP interpreter to read the file and process it into an HTML page. As part of this process, PHP may talk to a MySQL database and use that to generate the page. Lastly, PHP gives the final HTML code to Apache to send to the user’s browser.
So, far so good?
Now, Node is a bit different. It’s a programming language like PHP that lets you talk to database, make dynamic pages, etc. However, it differs in that it includes an HTTP server. That means that it can actually act completely on its own without nginx or Apache. You can just run Node and it will be the HTTP server and also the “app server” (which actually creates your dynamic pages and talks to the DB).
It’s a two for one deal.
Last thing to know is that when people actually deploy Node on the internet, they sometimes put another HTTP server like nginx in front of Node. That means that when a user loads a page, it first hits Nginx which can make a decision about where to route the request. This is handy if you have a big site and need to run many Node instances to handle all your traffic. This way, the single nginx server can split the work to be done among many Node.js “app servers”.
I necessarily simplified things here and there, but this is the general idea. Hopefully, this all made sense and I answered your question in there somewhere.
For Beginners this link is very useful: http://blog.modulus.io/absolute-beginners-guide-to-nodejs