7. Modern Computer Latency
● reaching RAM is like going from here to the
Red Light District.
● Accessing the network is like going to the
moon.
so, what shall we do?
8. we have processes!
time to use our gizillions cores!
● does not scale well, hundreds of connections
means hundreds of processes.
● Spinning up a new process takes
significantly more memory, a megabyte on
some platforms.
9. we have threads!
● Coarse-grained locks – more blocking
● Fine-grained locks – more complexity
● Risk for deadlocks
● Hard to reason about and therefore to get
right
● Context switching overhead
10. we have libraries!
There are asynchronous I/O libraries for Ruby
as well, like EventMachine or Cool.IO for
example.
And of course there's Twisted for Python,
Async, Event and EV for Perl, Rx for .NET,
Async Computation Expressions for F# and
libaio, libevent and libev for C. (BTW: Node.js is
actually implemented using libev)
11. we have libraries!
When you are within the event loop, you cannot
make any blocking calls. However, pretty much
the entire Ruby IO, File and Dir classes, as well
as the networking and database libraries and
so on are all mostly synchronous and blocking.
(And the same is true for pretty much all of the
other languages as well.) So, when you write
code in EventMachine or Cool.IO or Twisted,
you have to be very careful which methods you
call and which libraries you use in order to
avoid accidentally making blocking I/O calls.
12. nginx vs. apache
● Apache uses 1 thread per connection.
○ 1 thread per connection is limiting for massive
concurrency
● Nginx doesn't use threads
○ it runs an event loop
○ small memory allocation per connection
○ Especially relevant when dealing with I/O All code
runs in a single thread
○ No need for multithreading – no locks!
16. why should i care?
● I love Ruby
● I can use EventMachine for async
● And, after all, my Rails app doesn't have
youporn’s traffic
17. what do we want?
● closures
● event-driven language (callbacks)
● easy to code
● non-blocking, no processes/threads hassle
● widely use
window.onload = function() {
alert("Apollo 11 landed!")
}
d
18. ● Ruby is a programming language and Rails
is a web application framework.
● Node.js is neither a language nor an
application framework, it's an asynchronous
I/O library.
● ECMAScript is crap- can't read files, load
scripts, access the network. You can't even
access the friggin' web! (which is kind of
ironic for a web scripting language)
=> Node is great!
19. ● A set of bindings to Google’s V8 Javascript
VM (fast, super-duper fast)
● A purely evented, non-blocking infrastructure
that makes it super simple to build highly
concurrent programs
● Ability to handle thousands of concurrent
connections with minimal overhead on a
single process
● all blocking I/O written from scratch (in C)
● CommonJS module format
● one code to rule them all!
20. node is
● only exposes non-blocking asynchronous
interfaces
● only one thread, one stack (like browser)
● low level features: fs, tcp, udp
● has killer HTTP support
23. installing node.js
> brew install node.js
or
> git clone http://github.com/ry/node.git && cd
node
> ./configure && make && make install
24. time to code!
demo - node console, global, process, version,
env, pid, hello world
25. CommonJS & Modules
CommonJS is a community driven effort to
standardize packaging of JavaScript
libraries, known as modules.
Modules written which comply to this
standard provide portability between other
compliant frameworks such as narwhal, and
in some cases even browsers.
31. 'ruby is so yesterday's news'...
● Tower.js
● RailwayJS
32. RailwayJS
● full stack MVC framework.
● Doing to Node what Rails has done to Ruby.
> sudo npm install railway -g
> railway init blog && cd blog
> npm install -l
> railway generate crud post title content
> railway server 8888
> open http://127.0.0.1:8888/posts