Scott Moss
Frontend Masters
tldr; Environmentย to run JavaScript outside a browser
tldr; Pretty much anything a scripting and server language like python or ruby can, but with JavaScript
tldr; Use NVM
tldr; REPL for playing around, cli for everything else
ย
node path/to/your/file.js
process - has information about the environment the program is running in
requireย - function to find and use modules in current module
__dirname - the current directory path
module - information about current module, methods or making module consumable
global - like window, its the "global" object. Almost NEVER use this
.... many more
tldr; Nodejs gives you helpful globals, but just like the browser, you should not create your own
tldr; Encapsulated code
var module1 = (function(exports, require, module, __filename, __dirname){
// your node js code in a file
})
var module2 = (function(exports, require, module, __filename, __dirname){
// your node js code in another file
})
NodeJs uses commonJs for its module system.
tldr; CommonJs
There are other module systems out there like:
All your Nodejs code are modules.
tldr; Regular code, just export it
As the author, you decide how and what to expose from your modules, to other modules.
You do this with the module global object provided you by the Nodejs runtime
The Nodejs runtime injects another global, require.
tldr; require
This function takes a relative path to the module that you want to consume, and synchronously loads it by returning whatever the target module exported.
tldr; Nodejs ships with a bunch of helpful modules already
Nodejs has grown a bunch, and a bunch of that growth is due to its community and the ability to share modules and consume them at will.ย
tldr; download and use other modules from the internets ๐
You can slap together an app really fast by reusing public modules. Which are the same as the modules you make, but packaged for downloading
This sounds nice, but now you have to be aware of malicious code. Also, you need a system to help with the management of remote modules (downloading, publishing, updating, etc)
tldr; modules you created are always relative paths. ".js" is implied
var lib = require('../rel/path/to/lib') // Always have to use a "." first
var lib = require('lib') // the same name you used to install it with npm
var fs = require('fs') // internal module, remote module with same name takes it
tldr; CLI to manage remote modules
You'll be creating a CLI program that saves and retrieves contacts from and address book. The program is partially there, however, you must install some remote modules, and use the fileSystem to get some things to work.
Nodejs is single threaded and event based. Just like the browser.ย
tldr; Nodejs is single threaded and async like the browser, but you'll probably do more async things
Unlike the browser, your nodejs app will be shared by all clientsย
You now have consider CPU intensive tasks that block the single thread (while loops)
tldr; async / await is legit
// callback takes error as first arg, and result as second
doAsyncThing((error, result) => {})
doAsyncThing()
.then(result => {})
.catch(error => {})
const run = async () => {
const results = await doAsyncThing() // must return a promise
console.log('hello')
}
Any thrown or unhandled errors will cause the process to crash and exit
tldr; Errors kill your app, just like the browser
Your app may have errors that should not cause a crash, so you must handle accordingly
A server's job is to handle a request from some sor of client (browser, mobile app, another server, etc)
tldr; one server, handling many requests from clients
Without considering scaling, one server instance will handle many client requests. Compared to a client app where that code only cared about itself on the host machine
Nodejs has built in and community packakes for build all types of servers (API's, static, realtime. etc)
ย
You'll be refactoring and fixing a simple static asset server. The server uses blocking sync code and crashes whenever a request comes in that is asking for an asset that is not found. Neither of those are desirable. You'll also have to teach the server how to server the assets it has in the assets folder.
ย
Level 1
Use console.log to log your way through fixing your app. In production, record your logs
tldr; just like chrome
Level 2
Use the node inspector when starting your app and debug just like you would an browser app in chrome
Level 3
Text editor integration offers the most seamless experience.
Before you can test your code, make sure it is testable. As long as you can export what you want to test, you should be able to test it. There are other concerns specific to what libraries and frameworks you use
tldr; export your modules and use a testing framework
You can test pretty much anything in Nodejs. Browser apps, API's, CLI's, scripts, tools, etc. Your test themselves will be executed in Nodejs, so they have the ability to pretty much do anything.
tldr; many tools for the same job
tldr; everything can be tested with node
You have to debug and track down some issues in a small app. Use your logging and inspector to find them. Try and fix them, once you do, write some test to make sure it stays fixed ๐๐พ๐๐ฏ
Sharing your modules are easy. Just a few things you have to check:
tldr; push code to github, publish to NPM
Each cloud provider has is own method of deploying your apps on their platforms. Most of them have some integration with Github or a CLI to assist.
tldr; follow cloud provider instructions, and never hard code secrets
Few things to remember
Deploy one of the exercises to heroku (server) or npm (cli)