Slides da un seminario tenuto a maggio 2012. Universita' di milano, sede di Crema - Dipartimento di informatica.

1. Benvenuti

3. Luciano Colosio
@unlucio
CTO @ SaveTheMom Inc.
Federico Gandellini
@gandellinux
Freelance Developer

4. INDEX
• Node.js: la storia
• Node.js distilled: SyncVS Async
• Clouding
• Uso di node come Backend API

5. Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network
applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and
efficient, perfect for data-intensive real-time applications that run across distributed devices.
CurrentVersion: v0.8.21

6. RYAN DAHL
node.js creator
anno: 2009

7. RYAN DAHL
Studente in Matematica
Si trasferisce in Sud America
Incontra un programmatore php
Inizia a sviluppare siti ed “applicazioni” web
Incontra ROR
Si accorge che il Web e’ lento!

8. Il Web e’ lento!
Per via di Java ;)

9. Il Web e’ lento!
Alcuni cominciano a lavorare per velocizzare ROR

10. Il Web e’ lento!
Alcuni cominciano a lavorare per velocizzare ROR
Ma il problema risiede nell’intero stack

11. Il Web e’ lento!
Alcuni cominciano a lavorare per velocizzare ROR
Ma il problema risiede nell’intero stack
Il lavoro di Zed Shaw da vita a Mongrel

12. Mongrel

13. Mongrel
E’ sia una libreria http, sia un webserver!

14. Mongrel
E’ sia una libreria http, sia un webserver!
Il web server non e’ piu’ solo “una directory “

15. Mongrel
E’ sia una libreria http, sia un webserver!
Il web server non e’ piu’ solo “una directory “
Puo’ racchiudere direttamente la logica

16. Il Web Server

17. Il Web Server
Distillato, e’ fatto per gestire richieste e risposte

18. Il Web Server
Distillato, e’ fatto per gestire richieste e risposte
Servire files e’ una parte ma non e’ obbligatoria

19. THE FILE UPLOAD PROBLEM

20. THE FILE UPLOAD PROBLEM
Caricare files via http non era poi cosi’ comune

21. THE FILE UPLOAD PROBLEM
Caricare files via http non era poi cosi’ comune
Con la nascita di Ajax si cominciavano a caricareVIDEO!

22. THE FILE UPLOAD PROBLEM
Caricare files via http non era poi cosi’ comune
Con la nascita di Ajax si cominciavano a caricareVIDEO!
Ed ecco un nuovo problema da affrontare:

23. LA PROGRESS BAR

24. LA PROGRESS BAR
Il DOM non dava alcuna informazione sul file

25. LA PROGRESS BAR
Il DOM non dava alcuna informazione sul file
Il trucco era controllare lo stato del file lato server in batch.

26. LA PROGRESS BAR
Il DOM non dava alcuna informazione sul file
Il trucco era controllare lo stato del file lato server in batch.
Ma l’http 1.1 ci da connessioni che possono restare aperte!

27. LA PROGRESS BAR
Il DOM non dava alcuna informazione sul file
Il trucco era controllare lo stato del file lato server in batch.
Ma l’http 1.1 ci da connessioni che possono restare aperte!
Nasce un interessante plugin per Mongrel

28. IL LONG POLLING

29. IL LONG POLLING
Non piu’ continue richieste Ajax temporizzate

30. IL LONG POLLING
Non piu’ continue richieste Ajax temporizzate
Il Web Server risponde e non chiude subito la connessione

31. IL LONG POLLING
Non piu’ continue richieste Ajax temporizzate
Il Web Server risponde e non chiude subito la connessione
La connessione resta aperta finche’ la si puo’ usare

32. IL LONG POLLING
Non piu’ continue richieste Ajax temporizzate
Il Web Server risponde e non chiude subito la connessione
La connessione resta aperta finche’ la si puo’ usare
Il Server continua a spedire lo stato del file fino al termine

33. IL WEB SERVER E’APPENA
DIVENTATO MOLTO PIU’
INTELLIGENTE! :)

34. MA...

35. IL WEB E’ANCORA LENTO!

36. IL WEB E’ANCORA LENTO!
Ruby, Python, ecc sono troppo lenti by design

37. IL WEB E’ANCORA LENTO!
Ruby, Python, ecc sono troppo lenti by design
Gli interpreti sono singoli thread bloccanti

38. IL WEB E’ANCORA LENTO!
Ruby, Python, ecc sono troppo lenti by design
Gli interpreti sono singoli thread bloccanti
Il C e’ veloce ma uno sconosciuto per troppi webdev

39. SI SPERIMENTA CON:

40. SI SPERIMENTA CON:
Ruby

41. SI SPERIMENTA CON:
Ruby
Python

42. SI SPERIMENTA CON:
Ruby
Python
Askel

43. L’OBIETTIVO:

44. L’OBIETTIVO:
Costruire un sistema libero da lock!

45. LA RISPOSTA:

46. LA RISPOSTA:
Tutto in un solo thread

47. LA RISPOSTA:
Tutto in un solo thread
Migliora?

48. LA RISPOSTA:
Tutto in un solo thread
Migliora?
SI! Si possono evitare tutti i problemi derivanti dai lock!

49. LA RISPOSTA:
Tutto in un solo thread
Migliora?
SI! Si possono evitare tutti i problemi derivanti dai lock!
C’e’ un linguaggio che tutto cio’ lo fa di natura:

50. JAVASCRIPT

51. JAVASCRIPT
Negli ultimi anni ha preso sempre piu’ piede

52. JAVASCRIPT
Negli ultimi anni ha preso sempre piu’ piede
Tutti i maggiori browser stavano gia’ “combattendo su js”

53. JAVASCRIPT
Negli ultimi anni ha preso sempre piu’ piede
Tutti i maggiori browser stavano gia’ “combattendo su js”
Nel 2008 era stato rilasciatoV8

54. JAVASCRIPT
Negli ultimi anni ha preso sempre piu’ piede
Tutti i maggiori browser stavano gia’ “combattendo su js”
Nel 2008 era stato rilasciatoV8
Ha le caratteristiche adatte:

55. JAVASCRIPT
Negli ultimi anni ha preso sempre piu’ piede
Tutti i maggiori browser stavano gia’ “combattendo su js”
Nel 2008 era stato rilasciatoV8
Ha le caratteristiche adatte:
Closures

56. JAVASCRIPT
Negli ultimi anni ha preso sempre piu’ piede
Tutti i maggiori browser stavano gia’ “combattendo su js”
Nel 2008 era stato rilasciatoV8
Ha le caratteristiche adatte:
Closures
Funzioni anonime

57. JAVASCRIPT
Negli ultimi anni ha preso sempre piu’ piede
Tutti i maggiori browser stavano gia’ “combattendo su js”
Nel 2008 era stato rilasciatoV8
Ha le caratteristiche adatte:
Closures
Funzioni anonime
Non e’ usato al di fuori dei browser

58. JAVASCRIPT
Negli ultimi anni ha preso sempre piu’ piede
Tutti i maggiori browser stavano gia’ “combattendo su js”
Nel 2008 era stato rilasciatoV8
Ha le caratteristiche adatte:
Closures
Funzioni anonime
Non e’ usato al di fuori dei browser
Quindi non ha preconcetti su come fare le cose.

59. NASCE NODE.JS

60. NASCE NODE.JS
Viene presentato alla javascript conf di Berlino

61. NASCE NODE.JS
Viene presentato alla javascript conf di Berlino
La prima app di demo: un IRC Server, 400 linee di codice!

62. NASCE NODE.JS
Viene presentato alla javascript conf di Berlino
La prima app di demo: un IRC Server, 400 linee di codice!
Ed e’ fatto per costruire network servers!

63. NASCE NODE.JS
Viene presentato alla javascript conf di Berlino
La prima app di demo: un IRC Server, 400 linee di codice!
Ed e’ fatto per costruire network servers!
Il suo nome indica che e’ fatto per essere un nodo tra molti

64. NASCE NODE.JS
Viene presentato alla javascript conf di Berlino
La prima app di demo: un IRC Server, 400 linee di codice!
Ed e’ fatto per costruire network servers!
Il suo nome indica che e’ fatto per essere un nodo tra molti
E’ adatto alla Cloud* per sua natura.
*Una volta si chiamava internet

65. MA...

66. È:
JAVASCRIPT
NEL
SERVER!

67. È:
JAVASCRIPT
NEL
SERVER!

68. È:
JAVASCRIPT
NEL
SERVER!

69. JAVASCRIPT

70. JAVASCRIPT
[]+[] =

71. JAVASCRIPT
[]+[] = ‘’

72. JAVASCRIPT
[]+[] = ‘’
[]+{} =

73. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]

74. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]
{}+[] =

75. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]
{}+[] = 0

76. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]
{}+[] = 0
{}+{} =

77. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]
{}+[] = 0
{}+{} = NaN

78. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]
{}+[] = 0
{}+{} = NaN
‘’-1 =

79. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]
{}+[] = 0
{}+{} = NaN
‘’-1 = -1

80. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]
{}+[] = 0
{}+{} = NaN
‘’-1 = -1
‘string’-1 =

81. JAVASCRIPT
[]+[] = ‘’
[]+{} = [object Object]
{}+[] = 0
{}+{} = NaN
‘’-1 = -1
‘string’-1 = NaN

84. PARLIAMONE...

85. SPEED:

86. SPEED:
“Javascript e’ lento”

87. SPEED:
“Javascript e’ lento”
sbagliato, e’ la DOM API ad essere lenta!

88. SPEED:
“Javascript e’ lento”
sbagliato, e’ la DOM API ad essere lenta!
“Per essere non-blocking non bisogna fare I/O”

89. SPEED:
“Javascript e’ lento”
sbagliato, e’ la DOM API ad essere lenta!
“Per essere non-blocking non bisogna fare I/O”
ma node gestisce l’I/O per noi!

90. SPEED:
“Javascript e’ lento”
sbagliato, e’ la DOM API ad essere lenta!
“Per essere non-blocking non bisogna fare I/O”
ma node gestisce l’I/O per noi!
“Operazioni cpu-bound saranno lente e bloccanti”

91. SPEED:
“Javascript e’ lento”
sbagliato, e’ la DOM API ad essere lenta!
“Per essere non-blocking non bisogna fare I/O”
ma node gestisce l’I/O per noi!
“Operazioni cpu-bound saranno lente e bloccanti”
node non nasce per questo genere di task,
comunqueV8 ci da un grosso aiuto:

92. credits: Daniel Clifford, Manager andTech LeadV8Team. (@Google I/O 2012)

93. ALTRO:

94. ALTRO:
“Necessita del proprio HTTP server interno”

95. ALTRO:
“Necessita del proprio HTTP server interno”
questo in realta’ e’ uno dei punti di forza di node
ed uno dei motivi per cui nasce

96. ALTRO:
“Necessita del proprio HTTP server interno”
questo in realta’ e’ uno dei punti di forza di node
ed uno dei motivi per cui nasce
“Necessita di cache/reverse proxy”

97. ALTRO:
“Necessita del proprio HTTP server interno”
questo in realta’ e’ uno dei punti di forza di node
ed uno dei motivi per cui nasce
“Necessita di cache/reverse proxy”
Nessuno al giorno d’oggi in produzione usa webserver
direttamente connessi ad internet,
i layer di apparati e logica sono ingenti

98. ALTRO:
“Necessita del proprio HTTP server interno”
questo in realta’ e’ uno dei punti di forza di node
ed uno dei motivi per cui nasce
“Necessita di cache/reverse proxy”
Nessuno al giorno d’oggi in produzione usa webserver
direttamente connessi ad internet,
i layer di apparati e logica sono ingenti
“Consuma molte risorse”

99. ALTRO:
“Necessita del proprio HTTP server interno”
questo in realta’ e’ uno dei punti di forza di node
ed uno dei motivi per cui nasce
“Necessita di cache/reverse proxy”
Nessuno al giorno d’oggi in produzione usa webserver
direttamente connessi ad internet,
i layer di apparati e logica sono ingenti
“Consuma molte risorse”
Le esperienze pratiche dimostrano ben altro, con
performaces impressionanti (rif: linkedin)

100. EBBENE SI’, SIAMO DEGLI
IDIOTI E LO USIAMO
SERIAMENTE! ;)

101. FATTI: IL COSTO DELL’I/O
• cache L1: 3 cicli
• cache L2: 14 cicli
• RAM: 250 cicli
• Disco: 41x10^6 cicli
• Network: 240x10^6 cicli

102. ASYNC E NEXTTICK

103. ASYNC E NEXTTICK
Il nostro codice javascript gira in un solo thread

104. ASYNC E NEXTTICK
Il nostro codice javascript gira in un solo thread
Node utilizza poi un thread-pool per gestire l’I/O

105. ASYNC E NEXTTICK
Ogni thread ha una coda di task ad eseguire
Il nostro codice javascript gira in un solo thread
Node utilizza poi un thread-pool per gestire l’I/O

106. ASYNC E NEXTTICK
Ogni thread ha una coda di task ad eseguire
Il nostro codice javascript gira in un solo thread
Node utilizza poi un thread-pool per gestire l’I/O
Ad ogniTick viene consumato un task nella coda

107. ASYNC E NEXTTICK
Ogni thread ha una coda di task ad eseguire
Il nostro codice javascript gira in un solo thread
Node utilizza poi un thread-pool per gestire l’I/O
Ad ogniTick viene consumato un task nella coda
Non dobbiamo curarci di problemi di concorrenza

108. //
Good:
write
files
asynchronously
fs.writeFile('message.txt',
'Hello
Node',
func@on
(err)
{
console.log("It's
saved
and
the
server
remains
responsive!");
});
//
BAD:
write
files
synchronously
fs.writeFileSync('message.txt',
'Hello
Node');
console.log("It's
saved,
but
you
just
blocked
ALL
requests!");
ASYNC VS SYNC

109. var http = require('http');
var server = http.createServer(function (request, response) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end("Hello Worldn");
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
HTTP SERVER

110. var http = require('http');
var server = http.createServer(function (request, response) {
var data = fs.readFileSync('message.txt');
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
SYNC READ AND DELIVER:
CPU FileSystem Network

111. var http = require('http');
var server = http.createServer(function (request, response) {
var data = fs.readFileSync('message.txt');
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
SYNC READ AND DELIVER:
CPU FileSystem Network

112. var http = require('http');
var server = http.createServer(function (request, response) {
var data = fs.readFileSync('message.txt');
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
SYNC READ AND DELIVER:
CPU FileSystem Network

113. var http = require('http');
var server = http.createServer(function (request, response) {
var data = fs.readFileSync('message.txt');
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
SYNC READ AND DELIVER:
CPU FileSystem Network

114. var http = require('http');
var server = http.createServer(function (request, response) {
var data = fs.readFileSync('message.txt');
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
SYNC READ AND DELIVER:
CPU FileSystem Network

115. var http = require('http');
var server = http.createServer(function (request, response) {
fs.readFile('message.txt', function (err, data) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
});
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
ASYNC READ AND DELIVER:
CPU FileSystem Network

116. var http = require('http');
var server = http.createServer(function (request, response) {
fs.readFile('message.txt', function (err, data) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
});
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
ASYNC READ AND DELIVER:
CPU FileSystem Network

117. var http = require('http');
var server = http.createServer(function (request, response) {
fs.readFile('message.txt', function (err, data) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
});
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
ASYNC READ AND DELIVER:
CPU FileSystem Network

118. var http = require('http');
var server = http.createServer(function (request, response) {
fs.readFile('message.txt', function (err, data) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
});
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
ASYNC READ AND DELIVER:
CPU FileSystem Network

119. var http = require('http');
var server = http.createServer(function (request, response) {
fs.readFile('message.txt', function (err, data) {
response.writeHead(200, {"Content-Type": "text/plain"});
response.end(data.toString());
});
[ ... altri task ...]
});
server.listen(8000);
console.log("Server running at http://127.0.0.1:8000/");
ASYNC READ AND DELIVER:
CPU FileSystem Network

120. SYNC READ AND DELIVER:
CPU FileSystem Network
ASYNC READ AND DELIVER:

121. NODE DOC CIT.
users of Node are free from worries of dead-locking the
process there are no locks.Almost no function in Node
directly performs I/O, so the process never blocks. Because
nothing blocks, less-than-expert programmers are able to
develop fast systems.
[...]
Node simply enters the event loop after executing the input
script. Node exits the event loop when there are no more
callbacks to perform.This behavior is like browser javascript
the event loop is hidden from the user.
https://github.com/joyent/libuv/blob/master/src/unix/threadpool.c#L32

122. var
server
=
require('./lib/node-­‐router').getServer();
server.get("/json",
func@on
(req,
res,
match)
{
return
{hello:
"World"};
});
server.post(new
RegExp("^/(.*)$"),
func@on
hello(req,
res,
match)
{
return
"Hello
"
+
(match
||
"World")
+
"!";
});
server.listen(8080);
REST API
sfruttando una semplice libreria siamo subito piu’ comodi

123. Internet
The Cloud!

124. PRIMA:

125. PRIMA:
Server dedicati o server condivisi

126. PRIMA:
Server dedicati o server condivisi
POI:

127. PRIMA:
Server dedicati o server condivisi
POI:
I server vengono virtualizzati: leVPS

128. ARRIVA LA CLOUD:

129. ARRIVA LA CLOUD:
PaaS: Platform as a Service

130. ARRIVA LA CLOUD:
PaaS: Platform as a Service
le nostre aplicazioni girano in contenitori virtuali

131. ARRIVA LA CLOUD:
PaaS: Platform as a Service
le nostre aplicazioni girano in contenitori virtuali
i contenitori vengono replicati regionalmente

132. ARRIVA LA CLOUD:
PaaS: Platform as a Service
le nostre aplicazioni girano in contenitori virtuali
i contenitori vengono replicati regionalmente
anche leVPS imparano questi nuovi “trucchi “

133. VANTAGGI:

134. VANTAGGI:
e’ decisamente piu’ semplice scalare globalmente

135. VANTAGGI:
e’ decisamente piu’ semplice scalare globalmente
non dobbiamo piu’ gestire l’infrastruttura

136. VANTAGGI:
e’ decisamente piu’ semplice scalare globalmente
non dobbiamo piu’ gestire l’infrastruttura
pay per use

137. VANTAGGI:
e’ decisamente piu’ semplice scalare globalmente
non dobbiamo piu’ gestire l’infrastruttura
pay per use
aumentiamo o diminuiamo le nostre istanze con un click

138. VANTAGGI:
e’ decisamente piu’ semplice scalare globalmente
non dobbiamo piu’ gestire l’infrastruttura
pay per use
aumentiamo o diminuiamo le nostre istanze con un click
Il deploy si risolve con un git push!

139. MA...*E te pareva...

140. MA...
il nostro stack diventa “blando”

141. MA...
il nostro stack diventa “blando”
impatto piu’ evidente: le sessions

142. MA...
il nostro stack diventa “blando”
impatto piu’ evidente: le sessions
soluzioni come memcache o session-on-db
si rivelano spesso “corte” e costose

143. MA...
il nostro stack diventa “blando”
impatto piu’ evidente: le sessions
soluzioni come memcache o session-on-db
si rivelano spesso “corte” e costose
soluzione: data driven single page application

144. MA...
il nostro stack diventa “blando”
impatto piu’ evidente: le sessions
soluzioni come memcache o session-on-db
si rivelano spesso “corte” e costose
soluzione: data driven single page application
possiamo mutare il backend in web API! meglio se real time*
*E chi e’ bravo nel real time? :)

145. MA...
il nostro stack diventa “blando”
impatto piu’ evidente: le sessions
soluzioni come memcache o session-on-db
si rivelano spesso “corte” e costose
soluzione: data driven single page application
possiamo mutare il backend in web API! meglio se real time*
*E chi e’ bravo nel real time? :)
sfruttiamo a pieno la OOP: piu’ siamo puliti piu’ vantaggi.

146. MA...
il nostro stack diventa “blando”
impatto piu’ evidente: le sessions
soluzioni come memcache o session-on-db
si rivelano spesso “corte” e costose
soluzione: data driven single page application
possiamo mutare il backend in web API! meglio se real time*
*E chi e’ bravo nel real time? :)
sfruttiamo a pieno la OOP: piu’ siamo puliti piu’ vantaggi.
oggetti piccoli e specializzati risultano piu’ facili da distribuire

147. MA...
il nostro stack diventa “blando”
impatto piu’ evidente: le sessions
soluzioni come memcache o session-on-db
si rivelano spesso “corte” e costose
soluzione: data driven single page application
possiamo mutare il backend in web API! meglio se real time*
*E chi e’ bravo nel real time? :)
sfruttiamo a pieno la OOP: piu’ siamo puliti piu’ vantaggi.
oggetti piccoli e specializzati risultano piu’ facili da distribuire
con l’aiuto di bus e code distribuiamo i processi nei paas

148. E NODE?

149. E NODE?
beh, nodejs ci va a nozze!

150. E NODE?
beh, nodejs ci va a nozze!
il modello single thread e’ perfetto per i Paas

151. E NODE?
beh, nodejs ci va a nozze!
il modello single thread e’ perfetto per i Paas
i moduli possono essere distruibuiti facilmente
essendo ad eventi va in idle quando non lavora e costa meno

152. E NODE?
beh, nodejs ci va a nozze!
il modello single thread e’ perfetto per i Paas
i moduli possono essere distruibuiti facilmente
essendo ad eventi va in idle quando non lavora e costa meno
sfruttando l’async rispondiamo valocemente all’utente
demandando elaborazioni successive o costose in callbacks,
processi o istanze diverse distrubuendo meglio il carico

153. User NODE
NODE
Client Web Engine
Database
Logging facility
Mass storage
(big slow disk)
DB
Disk
ESEMPIO DI ARCHITETTURA
In questo modo i logs non rallentano piu’ i processi critici

154. backend
server
Mobile client
NodeJs
instances
Mobile Client
ESEMPIO: LINKEDIN
Linkedin usa node.js come middleware layer tra il backend e le
applicazioni mobile

155. backend
server
Mobile client
NodeJs
instances
Mobile Client
ESEMPIO: LINKEDIN
Linkedin usa node.js come middleware layer tra il backend e le
applicazioni mobile

156. backend
server
Mobile client
NodeJs
instances
Mobile Client
ESEMPIO: LINKEDIN
Linkedin usa node.js come middleware layer tra il backend e le
applicazioni mobile
VANTAGGI:

157. backend
server
Mobile client
NodeJs
instances
Mobile Client
ESEMPIO: LINKEDIN
Linkedin usa node.js come middleware layer tra il backend e le
applicazioni mobile
VANTAGGI:
migliori prestazioni: node si rivela 20x piu’ veloce di Rails

158. backend
server
Mobile client
NodeJs
instances
Mobile Client
ESEMPIO: LINKEDIN
Linkedin usa node.js come middleware layer tra il backend e le
applicazioni mobile
VANTAGGI:
migliori prestazioni: node si rivela 20x piu’ veloce di Rails
l’infrastruttura passa da 30 a 3 server
lasciando sufficienti risorse per scalare di 10 volte il traffico!

159. UN CASO COMPLESSO
Il backend di SaveThe Mom e’ tutto in node.js e ne sfrutta
pesantemente il modello asincrono con l’aiuto di bus e code

160. ED ORA: UN PO’ DI SPAM :)
HTTP://NODEJSCONF.IT

161. ED ORA: UN PO’ DI SPAM :)
HTTP://WEBDEBS.ORG

162. TROLLATECI SUTWITTER!
@UNLUCIO @GANDELLINUX

163. TROLLATECI SUTWITTER!
@UNLUCIO @GANDELLINUX

164. Grazie :)