Introduccion a Nodejs a Traves de Koans eBook

7/22/2019 Introduccion a Nodejs a Traves de Koans eBook

1/242


2/242


3/242

INTRODUCCIN A NODE.JS ATRAVS DE KOANS

Arturo Muoz de la Torre Monzn (@arturomtm)

Ingeniero de Teleco por la Universidad Politcnica de

Madrid. Entusiasta de las tecnologas que dan vida a la

Web. Curioso e imaginativo, siempre en evolucin.


4/242

Introduccin a Node.JS a travs de Koans

por Arturo Muoz de la Torre Monzn

http://nodejskoans.com

Revisin del texto:

D. Carlos ngel Iglesias Fernndez

Profesor en la Escuela Tcnica Superior de Ingenieros de

Telecomunicacin de la Universidad Politcnica de Madrid.

El contenido de esta obra (excepto el cdigo fuente)

est sujeto a una licencia Creative Commons Atribu-

cin - No comercial - CompartirIgual 3.0 Unported.

El cdigo fuente de los programas contenidos en esta obra, escritos por el

autor exclusivamente para ella, estn todos bajo una licencia GPL.

Koans for Node.js

Copyright (C) 2013 Arturo Muoz de la Torre

This program is free software: you can redistribute it and/or

modify it under the terms of the GNU General Public License as

published by the Free Software Foundation, either version 3 of

the License, or any later version.

This program is distributed in the hope that it will be useful,

but WITHOUT ANY WARRANTY; without even the implied warranty of

MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the

GNU General Public License for more details.

You should have received a copy of the GNU General Public Licensealong with this program. If not, see

.

El diseo de la portada ha corrido a cargo del autor del libro, empleando para ello

las tipografas: Bebas Neue, una versin modificada de la Aharoni Bold, Comfor-

taa, Tribal Animals Tatto Design(http://tattoowoo.com/)y Entypo pictograms

by Daniel Bruce (www.entypo.com).

2013-05-23
http://nodejskoans.com/http://tattoowoo.com/http://tattoowoo.com/http://tattoowoo.com/http://www.entypo.com/http://www.entypo.com/http://www.entypo.com/http://tattoowoo.com/http://nodejskoans.com/


5/242

A mis padres, Arturo y Fabi, y a

mi hermano Edu, por su apoyo y

confianza sin lmites.

A Irene, porque sin ella no hubie-

ra llegado nunca al final.


6/242


7/242

ndice general

ndice general I

ndice de Tablas V

ndice de Figuras VII

1. Introduccin 1

1.1. Qu son los Koans? . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

1.2. Gua de lectura. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.3. Conseguir el cdigo fuente . . . . . . . . . . . . . . . . . . . . . . . . . 6

2. Introduccin a Node v0.8 7

2.1. Qu es Node? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2. Es una plataforma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2.1. El proceso de arranque de Node . . . . . . . . . . . . . . . . . . 9

2.2.2. El formato CommonJS . . . . . . . . . . . . . . . . . . . . . . . 14

2.2.3. Mdulos disponibles en el core de Node . . . . . . . . . . . . . 15

2.2.4. Mdulos de terceras partes . . . . . . . . . . . . . . . . . . . . . 20

2.3. Construida encima del entorno de ejecucin de JavaScript de Chro-

me. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.1. El lenguaje JavaScript. . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.2. El motor V8 de Google. . . . . . . . . . . . . . . . . . . . . . . . 24

2.4. Fcil desarrollo de rpidas, escalables aplicaciones de red . . . . . 25

2.5. Usa E/S no bloqueante dirigida por eventos . . . . . . . . . . . . . . 27

2.5.1. El modelo de Concurrencia de Node . . . . . . . . . . . . . . . . 28

2.5.2. Arquitectura de Node . . . . . . . . . . . . . . . . . . . . . . . . 29

2.5.3. La clase EventEmitter . . . . . . . . . . . . . . . . . . . . . . . . 33

2.5.4. Postponiendo la ejecucin de funciones. . . . . . . . . . . . . . 34

2.6. Es ligero y eficiente [1] . . . . . . . . . . . . . . . . . . . . . . . . . . 35

I


8/242

2.7. Perfecto para aplicaciones en tiempo real data-intensive. . . . . . . 36

2.7.1. Tiempo real y Node. . . . . . . . . . . . . . . . . . . . . . . . . . 36

2.7.2. Para qu es til Node entonces? . . . . . . . . . . . . . . . . . 37

3. Mdulos Buffer y Dgram 39

3.1. Aspectos de UDP relevantes para Node . . . . . . . . . . . . . . . . . . 39

3.2. UDP en Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

3.3. Codificacin de caracteres . . . . . . . . . . . . . . . . . . . . . . . . . 44

3.4. Buffers en Javascript . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

3.5. Aplicacin con Buffers y UDP . . . . . . . . . . . . . . . . . . . . . . . 50

3.5.1. Descripcin del problema . . . . . . . . . . . . . . . . . . . . . . 50

3.5.2. Diseo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.5.2.1. El protocolo RTP . . . . . . . . . . . . . . . . . . . . . . 52

3.5.2.2. Descripcin de la solucin . . . . . . . . . . . . . . . . 54

3.6. Objetivos de los Koans . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

3.7. Preparacin del entorno y ejecucin de los Koans. . . . . . . . . . . . 62

3.8. Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

4. Mdulos Stream y Net 65

4.1. Aspectos de TCP relevantes para Node . . . . . . . . . . . . . . . . . . 654.2. Streams en Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.3. TCP en Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

4.4. Aplicacin con Streams TCP . . . . . . . . . . . . . . . . . . . . . . . . 78


4.4.2. Diseo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 79



4.7. Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

5. Mdulo Http 89

5.1. Aspectos de HTTP relevantes para Node . . . . . . . . . . . . . . . . . 89

5.1.1. La parte del Cliente . . . . . . . . . . . . . . . . . . . . . . . . . 91

5.1.2. La parte del Servidor. . . . . . . . . . . . . . . . . . . . . . . . . 96

5.2. HTTP en Node . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

5.2.1. ServerRequest . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

5.2.2. ServerResponse. . . . . . . . . . . . . . . . . . . . . . . . . . . . 104

5.2.3. Clientes HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

5.2.4. ClientResponse . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109

II


9/242

5.3. Aplicacin con HTTP. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110


5.3.2. Diseo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 112



5.6. Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119

6. Express 121

6.1. Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121

6.2. Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127

6.2.1. Request . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1316.2.2. Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132

6.3. MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134

6.4. Aplicacin de ejemplo . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139

6.4.1. Clon de Twitter, objetivo 1: autenticacin y control de sesiones 140

6.4.1.1. Descripcin del Objetivo. . . . . . . . . . . . . . . . . . 140

6.4.1.2. Diseo propuesto al Objetivo implementado con Ex-

press . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141

6.4.1.3. Objetivos de los Koans . . . . . . . . . . . . . . . . . . 149

6.4.1.4. Preparacin del entorno y ejecucin de los Koans . . . 150

6.4.2. Clon de Twitter, objetivo 2: publicacin de whizs y follow y

unfollow de otros usuarios . . . . . . . . . . . . . . . . . . . . . 151

6.4.2.1. Descripcin del Objetivo. . . . . . . . . . . . . . . . . . 151

6.4.2.2. Diseo propuesto al Objetivo implementado con Ex-

press . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151

6.4.2.3. Objetivos de los Koans . . . . . . . . . . . . . . . . . . 154

6.5. Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155

7. Socket.IO 157

7.1. Qu es Socket.IO? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

7.1.1. Socket.IO pretende hacer posible las aplicaciones en tiempo

real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157

7.1.2. en cada navegador y dispositivo mvil . . . . . . . . . . . . . 158

7.1.3. difuminando las diferencias entre los diferentes mecanismos

de transporte . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159

7.2. Usando Socket.IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

7.2.1. Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163

II I


10/242

7.2.2. Cliente [2] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167

7.3. Aplicacin con Socket.IO . . . . . . . . . . . . . . . . . . . . . . . . . . 176

7.3.1. Descripcin del juego . . . . . . . . . . . . . . . . . . . . . . . . 1767.3.2. Objetivos perseguidos . . . . . . . . . . . . . . . . . . . . . . . . 176

7.3.3. Diseo propuesto . . . . . . . . . . . . . . . . . . . . . . . . . . 177

7.3.4. Implementacin con Socket.IO . . . . . . . . . . . . . . . . . . . 181



7.6. Conclusin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188

8. Conclusin y trabajos futuros 189

A. Listados 191

A.1. Mdulos dgram y Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . 191

A.2. Mdulos netyStream . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196

A.3. Mdulo http . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201

A.4. Mdulo Express . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206

A.5. Mdulo Socket.IO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217

IV


11/242

ndice de tablas

5.1. Ejemplos de tipos MIME . . . . . . . . . . . . . . . . . . . . . . . . . . 94

6.1. Algunas de las variables configurables en los ajustes de Express . . . 129

V


12/242

VI


13/242

ndice de figuras

3.1. Reproductor VLC, Men Media . . . . . . . . . . . . . . . . . . . . . 51

3.2. Reproductor VLC, Open Network Stream . . . . . . . . . . . . . . . . 51

3.3. Reproductor VLC, configuracin de la IP . . . . . . . . . . . . . . . . . 52

3.4. Diagrama de Colaboracin de la Solucin RTP . . . . . . . . . . . . . 54

3.5. Ejecucin de Netcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63

3.6. Respuesta a la peticin con Netcat . . . . . . . . . . . . . . . . . . . . 64

4.1. Diagrama de Colaboracin de la Solucin TCP . . . . . . . . . . . . . 79

4.2. Telnet al puerto de la aplicacin . . . . . . . . . . . . . . . . . . . . . . 86

4.3. Reproductor VLC, configuracin . . . . . . . . . . . . . . . . . . . . . . 87

4.4. Solucin TCP, salida de los comandos . . . . . . . . . . . . . . . . . . 87

5.1. Interfaz de la Solucin HTTP . . . . . . . . . . . . . . . . . . . . . . . . 111

5.2. Autenticacin en la Solucin HTTP . . . . . . . . . . . . . . . . . . . . 111

5.3. Diagrama de colaboracin de la Solucin HTTP . . . . . . . . . . . . . 112

6.1. Creacin de las Colecciones en el promptde MongoDB. . . . . . . . . 140

6.2. Scaffoldingcreado por Express . . . . . . . . . . . . . . . . . . . . . . 142

6.3. Pgina principal de la aplicacin con Express . . . . . . . . . . . . . . 148

VI I


14/242

VI II


15/242

Captulo 1

Introduccin

Con el presente proyecto se pretenden establecer unas lneas de aprendizaje de

la plataforma Node a travs de un recorrido interactivo por sus principales m-

dulos, tanto propios como de terceras partes, con el que introducirse y asentar

sus principios bsicos de funcionamiento. A travs de seis captulos se quiere

proporcionar al lector de una amplia visin de qu herramientas pone Node a su

disposicin y cmo debe usarlas para realizar sus propios desarrollos.

Cada uno de estos captulos tratar uno o dos mdulos muy relacionados entre

s, con la intencin de que se cubran tpicos que vayan de menor complejidad a

mayor. La estructura de dichos captulos es siempre la misma:

un ligero repaso a los conceptos tericos que hay detrs del mdulo, general-

mente desgranando una RFC (Request For Comments), con especial nfasis

en aquellos que el API da opcin a manejar.

un recorrido por el API del mdulo no sintetizado, como pueda aparecer enla documentacin de Node, sino explicando la relaciones intrnsecas entre

los mtodos, propiedades y eventos del mdulo.

una propuesta de aplicacin a desarrollar que est basada en el mdulo que

se est tratando. Se procurar que la aplicacin cubra la mayor parte posible

de los conceptos que se destacaron en la introduccin terica.

el diseo propuesto al anterior problema, focalizando el desarrollo en aque-

llos puntos que usan las herramientas que el mdulo de Node proporciona

para cumplir con los requisitos que la especificacin anterior del problema

1


16/242

impone.

una seleccin de fragmentos de cdigo, cuyo dominio se considera obligato-rio para el conocimiento mnimo necesario del mdulo, de tal manera que

permitan desarrollar una aplicacin con l. Estos fragmentos son los can-

didatos para convertirse en Koans. Los Koans son la tcnica de aprendizaje

escogida para el proyecto. En los los prrafos siguientes se describir qu

son.

La seleccin de mdulos que se ha realizado viene motivada esencialmente por

un factor: Node est pensado para aplicaciones de red. Tiene sentido, por tanto,

que sean todos aquellos relacionados con este hecho. Y no slo dentro de losmdulos nativos de la plataforma, sino tambin aquellos que su popularidad entre

la comunidad de desarrolladores los ha hecho un estndar de facto. El proyecto

comprender pues los siguientes captulos:

Captulo 3: mdulos dgram y Buffer, o UDP como primera parada para ir

cogiendo la dinmica de la plataforma.

Captulo 4: mdulos net y stream, para introducir con TCP un punto de

complejidad en los protocolos de transporte.

Captulo 5: mdulo http, con el que subir un nivel en la pila de protocolos.

Captulo 6: mdulos Express, como la herramienta perfecta para la creacin

de aplicaciones web.

Captulo 7: mdulo Socket.IO, el paradigma de protocolo para las aplicacio-

nes en tiempo real.

Como se ha comentado unas lneas atrs, el mtodo elegido para el aprendizaje

interactivo de la plataforma son los Koans, pero...qu son los Koans?

1.1. Qu son los Koans?

El trmino koan proviene de la filosofa Zen oriental. Es el nombre que se le

da a un pequeo problema que un maestro plantea a su discpulo para evaluar

su progreso. Suelen ser breves y escuetos y, a menudo, con apariencia trivial o

absurda pero que, sin embargo, suponen para el discpulo un paso ms en su

2


17/242

camino hacia el despertar puesto que suponen para l realizar un esfuerzo para

entender la doctrina.

Los koans en el mbito informtico fueron idea de Joe OBrien y Jim Weirich, de

EdgeCase, como forma de alcanzar la iluminacin en el aprendizaje del lenguaje

Ruby. Manteniendo la analoga con la filosofa Zen, los koans de Ruby son peque-

os trozos de cdigo donde se sustituye alguna parte con unos guiones bajos __,

al estilo de los ejercicios de rellenar el hueco, que el alumno deber cambiar por el

cdigo que piense que es el correcto para que el ejercicio ejecute sin errores. Para

evaluar si lo que el alumno ha escrito en lugar de los __ es correcto se emplean

unos casos de prueba unitarios diseados para cada koan.

Posteriormente los koans se han extendido a ms lenguajes de programacin,

entre los que se incluyen JavaScript o Python.

La filosofa de los Koans que se han diseado para Node es la misma que la que

se ha presentado para los lenguajes de programacin: fragmentos de cdigo eva-

luables mediante pruebas unitarias que marquen al alumno el camino a seguir

para la correcta comprensin y asimilacin de los aspectos relevantes necesa-

rios para iniciarse en Node. Estos trozos de cdigo se engloban en el marco de

una aplicacin concreta, con lo que no son independientes entre s, sino que suresolucin lleva al alumno a tener en sus manos un programa con completa fun-

cionalidad donde entender mejor cules son los puntos clave ms bsicos cuando

se programa con Node como tecnologa de Servidor.

1.2. Gua de lectura

Con la intencin con la que se crearon los Koans se crea esta obra, cuyos captulos

van marcando el camino hacia el conocimiento y manejo de Node. El recorrido que

se marca para ello es el que sigue:

Captulo 2

El punto de partida que se va a tomar para introducir la programacin de

aplicaciones para Internet es uno de sus protocolos ms sencillos: UDP. Con

l se presentar el mdulo dgram, que implementa las caractersticas de

este protocolo, yBuffer, ntimente ligado a los protocolos de red porque es la

manera que tiene Node de manejar datos binarios sin un formato concreto,

en bruto.

3


18/242

Con dgramse tomar contacto con la creacin y gestin de conexiones UDP

y, sobre todo, con todo lo referente a operaciones de Entrada/Salida asn-

crona en redes, como envo y recepcin de datos.

ConBuffer, se conocer una de las clases bsicas de Node, siempre presente

en el espacio de ejecucin de cualquier programa, por lo que resulta impres-

cindible conocer cmo se crean y se manejan los datos que contiene a travs

de los mltiples mtodos que Bufferofrece para ello.

El pegamento que junta ambos mdulos es una aplicacin que implementa

el protocolo RTP (Real Time Protocol), basado en UDP, para transmitir can-

ciones a los clientes que lo soliciten.

Captulo 3

Siguiendo con los protocolos de red, se da un paso ms con respecto al tema

anterior y se introduce el mdulo net, que da soporte a la transmisin de

datos sobre el protocolo TCP, hemano mayor de UDP. Estos datos se ven

como un flujo continuo, o stream, con lo que la inclusin del mdulo stream

en este captulo cobra sentido.

TCP introduce mayor complejidad, lo que se traduce en mayor nmero de pa-rmetros a controlar en una transmisin, completando as los conocimientos

adquiridos en el tema anterior sobre comunicacin Cliente-Servidor. Ahora

se introducirn los mtodos especficos para TCP que se usan para gestionar

el ciclo de vida de una conexin: desde su generacin a su cierre, pasando

por la lectura y escritura de datos en ella.

El paso que se avanza con este captulo se refleja en la aplicacin ejemplo

que se plantea como problema: es una evolucin de la anterior, donde ahora

se incorpora soporte TCP para el control del envo del audio a los clientes.Se conseguir introduciendo un servidor TCP que acepte conexiones por las

que se reciban comandos en modo texto.

Captulo 4

Por encima del nivel de transporte, en el que se ubicaran los protocolos

vistos en los captulos anteriores, se encuentra el nivel de aplicacin para el

que Node tambin posee mdulos en su API. En concreto, para el Protocolo

de Transferencia de Hipertexto, HTTP, en el que se basa toda la Web.

La naturaleza de este mdulo es similiar a la de los anteriores puesto que

4


19/242

sigue el modelo Cliente-Servidor ya asimilado, pero se aaden ms carac-

tersticas propias de la especificacin HTTP. Por ello, junto al manejo de

conexiones HTTP se introducirn los mecanismos para gestionar peticionesinterpretando los mtodos y cabeceras propias del protocolo para generar

las respuestas de la manera ms adecuada.

Aunque HTTP se site por encima de TCP, no implica que no pueda convivir

con ms protocolos en una misma aplicacin. En este caso, en la aplicacin

de ejemplo, se utilizar junto con RTP para proporcionar una interfaz web

con la que controlar qu se emite porstreaming, simulando un reproductor

de audio tradicional.

Captulo 5

Una vez que se conocen las libreras fundamentales de Node es hora de

evolucionar y subir un peldao en la arquitectura de los mdulos de terceras

partes para la plataforma. Visto HTTP, se presentar la manera de tratar con

l desde otra perspectiva: la de la creacin de Aplicaciones Web.

Si se sigue el movimiento en la pila de una aplicacin web para Node puede

encontrarse con Connect y Express, dos de las libreras ms famosas del

entorno. Ambas hacen uso de los mdulos que ofrece Node para poner adisposicin del programador un middleware(Connect) y un framework web

(Express). A lo largo del captulo se aprender a configurar Connect para in-

corporar las diversas funcionalidades que ofrece y a hacer uso de la funcio-

nalidad enriquecida que aade Express a las peticiones y respuestas HTTP,

as como a entender el nivel de abstraccin que supone respecto del mdulo

nativo httpde Node.

Junto con ellas, se hablar de Mongoose, un driverpara Node para la base

de datos no relacional MongoDB. Este tipo de bases de datos estn muy

presentes en el desarrollo de las aplicaciones web ms modernas y, como

toda base de datos, son imprescindibles a la hora de desarrollar una solucin

completa. Por ser un drivermuy completo y complejo, se presentarn las

operaciones ms elementales que se pueden realizar con l para emprender

un desarrollo bsico pero perfectamente funcional.

Captulo 6

El ltimo peldao antes de adquirir una base ms o menos amplia sobre la

programacin para Internet con Node, son las aplicaciones en tiempo real,

5


20/242

las cuales estn adquiriendo, si es que no lo han hecho ya, una importancia

fundamental en cualquier desarrollo web.

Con este captulo se aprendern algunos de los conceptos realacionados

con ellas, y se afianzarn con un mdulo, Socket.IO, diseado para hacerlo

de una manera eficiente y sencilla. Se presentar su funcionamiento, cmo

realiza y gestiona todas las conexiones, tanto en la parte servidor como en la

cliente, y cmo se produce el intercambio de datos entre los mismos.

Siguiendo el mismo esquema que en captulos anteriores, se concluir con

el desarrollo de una aplicacin que haga uso de las mnimas partes necesa-

rias para obtener un comportamiento que responda a las caractersticas detiempo real. Para apreciarlas, qu mejor que un juego donde una interaccin

instantnea es obligada para una correcta experiencia de usuario.

1.3. Conseguir el cdigo fuente

Todo el cdigo que se ha generado para este proyecto puede localizarse en Git-

hub1, una comunidad de desarrolladores. El repositorio concreto donde se hallan

todos los archivos es uno en la cuenta personal del autor del libro, al que se ha lla-

mado nodejskoans: https://github.com/arturomtm/nodejskoans.git. Para

tener una copia con la que trabajar, es necesario clonarlo en un directorio de la

mquina de trabajo:

$ mkdir nodejskoans

$ cd nodejskoans

$ git clone https://github.com/arturomtm/nodejskoans.git

Una vez clonado, se puede trabajar con el cdigo tal y como se explica en loscaptulos que siguen.

1http://github.com

6
https://github.com/arturomtm/nodejskoans.githttp://github.com/http://github.com/https://github.com/arturomtm/nodejskoans.git


21/242

Captulo 2

Introduccin a Node v0.8

Node.js, de ahora en adelante Node, es un proyecto creado por Ryan Dahl a prin-

cipios de 2009. Se dise orientado a la creacin de aplicaciones para Internet,

principalmente Web, porque la programacin de software para servidores era el

tipo de desarrollo que haca el autor en aquella fecha.

La idea empez a gestarse a partir de otro proyecto para el framework Ruby on

Rails, un pequeo y rpido servidor web llamado Ebb, tambin de la autora deRyan Dahl, que evolucion a una librera en C [3]. El aspecto negativo de esto era

la complejidad que supone el lenguaje C para programar aplicaciones basadas en

dicha librera. Es en este punto donde entra en escena el, por aquel entonces, re-

cin aparecido intrprete de JavaScript de Google, V8, que no tard en adoptarse

como el motor de la plataforma emergente.

Una de las razones de la evolucin del proyecto desde Ruby a C, y luego de C a

JavaScript fue el objetivo de realizar un sistema en que la Entrada/Salida fuera

enteramente no bloqueante. Ryan tena claro que era esencial para obtener unalto rendimiento. Con Ruby y C siempre haba una parte del sistema que era

bloqueante. Pero JavaScript se ajusta a este requisito porque est diseado para

ejecutarse en un bucle de eventos, que es, precisamente, lo que Node hace: dele-

gar en la plataforma las operaciones de Entrada/Salida que solicita la aplicacin.

De esta manera Node puede seguir realizando tareas sin estar bloqueado espe-

rando, y cuando las operaciones se hayan completado, procesar en su bucle de

eventos el evento generado y ejecutar el cdigo que lo maneja segn se haya de-

finido. La consecuencia de este modelo Entrada/Salida es que se puede atender

a un altsimo nmero de clientes a la vez, motivo que ha llevado a Node a ser el

7


22/242

paradigma de plataforma de aplicaciones de tiempo real.

Desde la presentacin de Node, el proyecto no ha parado de crecer. Actualmente,

es el segundo repositorio ms popular en Github1,con ms de 20.000 seguidores,

y tiene ms de 24.794 libreras, a las que llaman mdulos, registradas en la web

de su gestor de paquetes, NPM2. Todo ello estando slo, a fecha de redaccin de

este proyecto, en la versin 0.8 (rama estable).

Adems de la gran actividad en Internet, a la que hay que sumarle el concurso

mundial de aplicaciones Node Knockout3, la comunidad de Node tiene una cita

anualmente con el ciclo de conferencias NodeConf4,donde se presentan todos los

avances de la plataforma, o con la JSConf5, un evento para desarrolladores de

JavaScript donde la plataforma es protagonista de muchas de las conferencias

que se realizan.

Node est apadrinado por la compaa Joyent6, que contrat a Ryan Dahl cuando

comenzaba el proyecto. Joyent ofrece, conjuntamente con Nodejistsu7, como IaaS,

un entorno en la Nube donde desplegar aplicaciones Node.

Pero no slo Joyent ofrece alojamiento para esta plataforma. Heroku8 tambin

tiene soluciones cloud-computingpersonalizables, y, si se eligen opciones gratuitas

yopen source, Nodester9 da espacio para aplicaciones como PasS.

Como colofn, Node fue galardonado en 2012 con el premio Tecnologa del Ao

por la revista InfoWorld, perteneciente a una divisin prestigioso grupo interna-

cional de prensa especializada IDG. Y, posiblemente, todo no haya hecho ms que

empezar.

1https://github.com2https://npmjs.org/3http://nodeknockout.com/4http://www.nodeconf.com5http://jsconf.com6http://joyent.com7https://www.nodejitsu.com/8

http://www.heroku.com9http://nodester.com

8


23/242

2.1. Qu es Node?

La mejor manera de aproximarse a Node es a travs de la definicin que aparece

en su pgina web: [4]

Node.js es una plataforma construida encima del entorno de ejecucin javascript

de Chrome para fcilmente construir rpidas, escalables aplicaciones de red.

Node.js usa un modelo de E/S no bloqueante dirigido por eventos que lo hace li-

gero y eficiente, perfecto para aplicaciones data-intensive en tiempo real

Esta visin global de Node se puede diseccionar en pequeas partes que, una vez

analizadas separadamente, dan una visin mucho ms precisa y detallada de lascaractersticas del proyecto.

2.2. Es una plataforma

En efecto, Node provee un entorno de ejecucin para un determinado lenguaje

de programacin y un conjunto de libreras bsicas, o mdulos nativos, a partir

de las cuales crear aplicaciones orientadas principalmente a las redes de comu-nicacin, aunque una parte de estas libreras permite interactuar con compo-

nentes del sistema operativo a travs de funciones que cumplen con el estndar

POSIX.

Bsicamente este estndar o familia de estndares define las interfaces y el en-

torno, as como utilidades comunes, que un sistema operativo debe soportar y

hacer disponibles para que el cdigo fuente de un programa sea portable (com-

pilable y ejecutable) en diferentes sistemas operativos que implementen dicho

estndar. En este caso, Node facilita funciones para manejo de archivos, Entra-

da/Salida, seales y procesos conformes a las caractersticas establecidas por

POSIX [5].

2.2.1. El proceso de arranque de Node

El cdigo que realiza el arranque, o bootstrap, del ncleo de la plataforma es

lo primero que se ejecuta y uno de sus cometidos es proveer el mecanismo pa-

ra cargar el resto de los mdulos del core segn vayan siendo necesarios o se

9


24/242

demanden. Se puede echar un vistazo a este cdigo en el fichero del cdigo fuen-

te src/node.js. Ah se ve que el encargado de realizar la carga es el objeto

NativeModule, que ofrece un minimalista sistema de gestin de mdulos.

Pero aparte de NativeModule, en el proceso de arranque ocurren muchas ms

cosas, de las que se encargan el resto de funciones presentes en node.js.

Una de las primeras acciones que se realizan es hacer disponibles las variables,

objetos y funciones globales. Por globales se entiende que estn disponibles en el

scopedonde corre Node, que se hace disponible al programa mediante, precisa-

mente, la variable global. Por defecto, disponemos de las funciones que ofrecen

los mdulos console y timers, el objeto Buffer, del mdulo buffer, y el objetonativo process.

Se hablar de process por ser quizs uno de los objetos ms interesantes de la

plataforma desde el punto de vista del diseo. Presente en el espacio global de

ejecucin del proceso principal de Node representa a ese mismo proceso. Como

se ha dicho, se hace disponible en l despus de crearse en cdigo nativo a tra-

vs de la funcin SetupProcessObject()en el proceso de arranque definido en

el fichero src/node.cc10. Con esta funcin se crea un objeto al que se le aa-

den propiedades y mtodos en cdigo nativo que luego estn disponibles para elprogramador a travs del API. stos permiten:

identificar la arquitectura y sistema operativo donde corre Node, mediante

las propiedades process.arch y process.platform, o con

process.features

tener conocimiento mnimo sobre el proceso de Node como su identificador

de proceso con process.pid, el directorio de trabajo con process.cwd(),

que se puede cambiar conprocess.chdir()

, el path desde donde se inicicon process.execPath, o las variables de entorno del usuario con

process.env

conocer versiones de Node y de libreras nativas con las propiedades

process.versionyprocess.versions

en caso de sistemas *nix, manejar identificadores de grupos y usuarios con

process.getuid(), process.setuid(), process.getgid() y

process.setgid()

10 node.cchttps://github.com/joyent/node/blob/v0.8.20-release/src/node.cc#L2166

10
https://github.com/joyent/node/blob/v0.8.20-release/src/node.cc#L2166https://github.com/joyent/node/blob/v0.8.20-release/src/node.cc#L2166


25/242

estadsticas de ejecucin como el tiempo que lleva corriendo el proceso, con

process.uptime() y la memoria que est consumiendo con

process.memoryUsage()

Adems, existen una serie de variables y mtodos no documentados del todo que

son interesantes desde el punto de vista de funcionamiento interno de Node:

se tiene un registro de los mdulos que se han cargado en la platafor-

ma, en el arrayprocess.moduleLoadList. En esta lista identificaremos

dos tipos de mdulos por la etiqueta que precede al nombre del mdulo:

NativeModuleyBinding.

NativeModulese refiere a los mdulos JavaScript que componen el core de

Node y se cargan a travs del objeto NativeModule.

Binding, por su parte, identifica a los mdulos escritos en C/C++ de ms

bajo nivel que los otros. Estosbindingso addons, ofrecen sus mtodos o sus

objetos al cdigo de un programa como si de otro mdulo ms se tratara, o,

en la arquitectura de Node, sirven como base a las libreras en JavaScript.

Un bindingse carga internamente con el mtodo process.binding(), que

no debera ser accesible para el desarrollador, aunque lo es y se puede invo-

car.

Resear que process.binding() no tiene nada que ver con

process.dlopen(), otro mtodo que tambin se puede invocar, aunque de-

be hacerlo siempre el cargador de mdulos, y que sirve para cargar los ad-

donsde terceras partes o que no forman parte del ncleo de Node. Son dos

maneras diferentes de cargar libreras, que en el fondo hacen lo mismo pero

con distinta finalidad.

se tiene tambin estadsticas de diagnstico del mencionado bucle de eventosa travs de process.uvCounters(). Obtendremos los contadores internos

del bucle de eventos que se incrementan cada vez que se registra un evento

en l.

Seguidamente, se termina de inicializar el objeto processya a nivel de cdigo no

nativo, sino JavaScript:

Se establece la clase EventEmittersu como prototipo, con lo cualproccess

hereda sus mtodos y por tanto la capacidad de generar eventos y notificarlo

a sus subscriptores. Se profundizar en EventEmittercuando se hable de

11


26/242

la arquitectura de Node.

Se establecen los mtodos de interaccin con el bucle de eventos 11

. El bu-cle de eventos es una caracterstica de la arquitectura de Node que tiene

mucho que ver con el altsimo rendimiento de la plataforma. Ms adelan-

te se analizar en detalle este punto. A nivel de programador, el API ofrece

process.nextTick().

Se inicializan losStreamsde Entrada/Salida estndar12.El API los presenta

como las propiedades: process.stdout, process.stderr, habilitados am-

bos para la escritura y, a diferencia de los dems Streams de Node, son

bloqueantes; yprocess.stdin que es de lectura y est pausado de iniciocuando la entrada estndar no es otro Stream, con lo que, para leer de l, se

debe abrir primero invocando aprocess.openStdin().

Se definen los mtodos relacionados con las seales13 del sistema operativo:

process.exit(), para terminar la ejecucin del programa especificando un

cdigo de salida, yprocess.kill(), para enviar seales a otros procesos,

tal y como se hara con la llamada al sistema operativo kill.

Se aade funcionalidad a los mtodos para manejar listeners

14

que heredade EventEmitter, recubrindolos para que sean capaces de escuchar y actuar

sobre seales del sistema operativo (tipo Unix), no slo eventos.

Se determina si, en lugar de ser el proceso principal de Node, el programa

es un proceso workerdel modulo cluster, de los que se hablar cuando se

comente el entorno de ejecucin de Node.

Por ltimo, se determinar en qu modo se va a ejecutar Node y se entra en l.

Actualmente hay varios modos:

Script

se accede a este modo pasando por lnea de comandos el nombre de un

fichero .jsque contiene el cdigo del programa. Node cargar ese fichero y

lo ejecutar. Es el modo ms comn de trabajar en la plataforma.

Tambin se puede indicar por lnea de comandos mediante el modificador-e

11node.jshttps://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L4712node.jshttps://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L35213

node.jshttps://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L43214 node.jshttps://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L464

12
https://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L47https://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L352https://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L432https://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L464https://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L464https://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L432https://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L352https://github.com/joyent/node/blob/v0.8.20-release/src/node.js#L47


27/242

o evalseguido del nombre del script.

REPLson las siglas de Read Eval Print Loop. Es el modo interactivo en el que

Node presenta un prompt (>) donde manualmente se van introduciendo

expresiones y comandos que sern evaluados al presionar la tecla Enter.

Debug

se invoca incluyendo el modificador debug en la lnea de comandos y deja

a Node en un modo interactivo de depuracin de scripts donde se pueden

introducir mediante comandos las acciones tpicas en este tipo de sesiones:

step in, step out, fijar y limpiar breakpoints...

Adicionalmente, los autores del proyecto permiten cargar cdigo propio del pro-

gramador y arrancar con l en lugar de hacerlo con el arranque normal de Node.

Para ello se debe incluir en el directorio lib/ del cdigo fuente del proyecto el

fichero _third_party_main.js que contendr el cdigo personalizado, y luego

compilarlo todo.

El objeto que carga las libreras, como se ha comentado, es NativeModuleel cual

ofrece un pequeo mecanismo para la carga y gestin de mdulos. Este mecanis-

mo es auxiliar y una vez cumple su funcin se reemplaza por la funcionalidad,

ms completa, que ofrece el mdulo module, cargado a su vez, paradjicamen-

te, porNativeModule. Cuando se desea tener disponible cualquier mdulo para

usarlo en un programa, el mtodo require() que se invoca es el de module15.

Este mtodo comprueba, con ayuda de NativeModule, si el mdulo est en la ca-

ch de mdulos y en caso negativo, lo busca en el sistema de ficheros o en caso

de que sea un mdulo del core de Node, en el propio ejecutable de la plataforma,

ya que stos estn embebidos en l [6]. Una vez localizado, lo compila, lo mete enla cach y devuelve su exports, es decir, las funciones, variables u objetos que el

mdulo pone a disposicin del programador.

Las libreras del core son tambin archivos de extensin .js que se hallan en

el directorio lib/ del cdigo fuente (pero empotrados en el ejecutable una vez

compilado, como se ha dicho). Cada uno de esos archivos es un mdulo que sigue

el formato que define CommonJS.

15

module.js https://github.com/joyent/node/blob/v0.8.20-release/lib/module.js#L377

13
https://github.com/joyent/node/blob/v0.8.20-release/lib/module.js#L377https://github.com/joyent/node/blob/v0.8.20-release/lib/module.js#L377https://github.com/joyent/node/blob/v0.8.20-release/lib/module.js#L377https://github.com/joyent/node/blob/v0.8.20-release/lib/module.js#L377


28/242

2.2.2. El formato CommonJS

CommonJSes una creciente coleccin de estndares que surgen de la necesidad

de completar aspectos que se echan en falta en la especificacin de JavaScript,

el lenguaje de programacin usado en Node. Entre estos aspectos perdidos se

pueden nombrar la falta de una API estndar y bien definida, la de unas interfaces

estndar para servidores web o bases de datos, la ausencia de un sistema de

gestin de paquetes y dependencias o, la que de mayor incumbencia: la falta de

un sistema de mdulos.[7]

Node soporta e implementa el sistema que CommonJS define para esta gestin

de mdulos, lo cual es importante no slo a la hora de organizar el cdigo sino

a la hora de asegurar que se ejecuta sin interferir en el cdigo de los dems

mdulos aislndolos unos de otros de tal manera que no haya conflicto entre, por

ejemplo, funciones o variables con el mismo nombre. A esto se le conoce como

scope isolation.

Las implicaciones del uno de este estndar son:[8]

El uso de la funcin require() para indicar que queremos emplear una

determinada librera pasndole el identificador de la librera (su nombre)como parmetro.

La existencia de la variable exports dentro de los mdulos. Esta variable

es un objeto que es el nico modo posible que tiene un mdulo de hacer

pblicas funciones y dems objetos, aadindolas a exports conforme se

ejecuta el cdigo de dicho mdulo.

La definicin dentro de un mdulo de la variable module. Esta variable es un

objeto con la propiedad obligatoriaidque identifica unvocamente al mduloy por tanto, se obtiene de l el exports que interese al desarrollador.

En definitiva, se puede hacer uso de las caractersticas que ofrezca un mdulo,

siempre y cuando ste las tenga aadidas a su exports, si se indica en el cdigo

con require(modulo).

Por ejemplo, el siguiente mdulo, al que se llamar circle y se usar en un pro-

grama cdigo gracias arequire(circle), permite calcular el rea y permetro

de cualquier circulo; sin embargo, no permite conocer el valor de la constante PI

ya que no la incluye en su exports:

14


29/242

var PI = 3.14;

exports.area = function (r) {

return PI * r * r;

};

exports.circumference = function (r) {

return 2 * PI * r;

};

2.2.3. Mdulos disponibles en el core de Node

Se dispone pues de una serie de mdulos que conforman el ncleo de Node y

que se pueden usar en las aplicaciones. Para utilizar la gran mayora de estas

libreras se debe indicar explcitamente, mediante la funcin require(), que,

como se ha visto, es el mecanismo que Node ofrece para tener disponibles los

exports de los mdulos. Sin embargo, como se ha comentado antes, hay una

serie de mdulos que estn disponibles implcitamente, ya que se cargan en el

proceso de bootstrap presente en src/node.js. El API los denominaGlobals y

ofrecen distintos objetos y funciones accesibles desde todos los mdulos, aunque

algunos de ellos slo en el mbito (scope) del mdulo, no en el mbito global (deprograma). Estos mdulos son:

console

marcado en el API como STDIO, ofrece el objeto consolepara imprimir men-

sajes por la salida estndar: stdout y stderr. Los mensajes van desde los

habituales infoo loghasta trazar la pila de errores con trace.

timers

ofrece las funciones globales para el manejo de contadores que realizarn

la accin especificada pasado el tiempo que se les programa. Debido a la

cmo est diseado Node, relacionado con el bucle de eventos del que se

hablar en un futuro, no se puede garantizar que el tiempo de ejecucin de

dicha accin sea exactamente el marcado, sino uno aproximado cercano a

l, cuando el bucle est en disposicin de hacerlo.

module

proporciona el sistema de mdulos segn impone CommonJS. Cada mdulo

que se carga o el propio programa, est modelado segn module, que se ver

como una variable,module, dentro del mismo mdulo. Con ella se tienen dis-

15


30/242

ponibles tanto el mecanismo de cargarequire()como aquellas funciones y

variables que exporta, en module.exports, que destacan entre otras menos

corrientes que estn a un nivel informativo: mdulo que ha cargado el actual(module.parent), mdulos que carga el actual

(module.children)...

buffer

es el objeto por defecto en Node para el manejo de datos binarios. Sin embar-

go, la introduccin en JavaScript de los typedArraysdesplazar a losBuffers

como manera de tratar esta clase de datos [9].

Los mdulos siguientes, listados por su identificador, tambin forman parte delncleo de Node, aunque no se cargan al inicio, pero se exponen a travs del

API:

util

conjunto de utilidades principalmente para saber de si un objeto es de tipo

array, error, fecha, expresin regular...Tambin ofrece un mecanismo para

extender clases de JavaScript a travs de herencia:

inherits(constructor, superConstructor);

events

provee la fundamental clase EventEmitter de la que cualquier objeto que

emite eventos en Node hereda. Si alguna clase del cdigo de un programa

debe emitir eventos, sta tiene que heredar de EventEmitter.

stream

interfaz abstracta que representa los flujos de caracteres de Unix de la cual

muchas clases en Node heredan.

crypto

algoritmos y capacidades de cifrado para otros mdulos y para el cdigo de

programa en general.

tls

comunicaciones cifradas en la capa de transporte con el protocolo TLS/SSL,

que proporciona infraestructura de clave pblica/privada.

string_decoder

proporciona una manera de, a partir de un Buffer, obtener cadenas de ca-

16


31/242

racteres codificados enutf-8.

fsfunciones para trabajar con el sistema de ficheros de la manera que es-

tablece el estndar POSIX. Todos los mtodos permiten trabajar de forma

asncrona (el programa sigue su curso y Node avisa cuando ha terminado

la operacin con el fichero) o sncrona (la ejecucin del programa se detiene

hasta que se haya completado la operacin con el fichero).

path

operaciones de manejo y transformacin de la ruta de archivos y directorios,

a nivel de nombre, sin consultar el sistema de ficheros.

net

creacin y manejo asncrono de servidores y clientes, que implementan la

interfaz Streammencionada antes, sobre el protocolo de transporte TCP.

dgram

creacin y manejo asncrono de datagramas sobre el protocolo transporte

UDP.

dnsmtodos para tratar con el protocolo DNS para la resolucin de nombres de

dominio de Internet.

http

interfaz de bajo nivel, ya que slo maneja los Streamsy el paso de mensa-

jes, para la creacin y uso de conexiones bajo el protocolo HTTP, tanto del

lado del cliente como del servidor. Diseada para dar soporte hasta a las

caractersticas ms complejas del protocolo comochunk-encoding.

https

versin del protocolo HTTP sobre conexiones seguras TLS/SSL.

url

formateo y anlisis de los campos de las URL.

querystrings

utilidades para trabajar con las queriesen el protocolo HTTP. Unaqueryson

los parmetros que se envan al servidor en las peticiones HTTP. Dependien-

do del tipo de peticin (GET o POST), pueden formar parte de la URL por lo

17


32/242

que deben codificarse o escaparse y concatenarse de una manera especial

para que sean interpretadas como tal.

readline

permite la lectura lnea por lnea de unStream, especialmente indicado para

el de la entrada estndar (STDIN).

repl

bucle de lectura y evaluacin de la entrada estndar, para incluir en pro-

gramas que necesiten uno. Es exactamente el mismo mdulo que usa Node

cuando se inicia sin argumentos, en el modo REPLcomentado con anterio-

ridad.

vm

compilacin y ejecucin bajo demanda de cdigo.

child_process

creacin de procesos hijos y comunicacin y manejo de su entrada, salida y

error estndar con ellos de una manera no bloqueante.

assert

funciones para la escritura de tests unitarios.

tty

permite ajustar el modo de trabajo de la entrada estndar si sta es un

terminal.

zlib

compresin/descompresin de Streams con los algoritmos zlib y gzip. Es-

tos formatos se usan, por ejemplo, en el protocolo HTTP para comprimir los

datos provenientes del servidor. Es conveniente tener en cuenta que los pro-cesos de compresin y descompresin pueden ser muy costosos en trminos

de memoria y consumo de CPU.

os

acceso a informacin relativa al sistema operativo y recursos hardware sobre

los que corre Node.

_debugger

es el depurador de cdigo que Node tiene incorporado, a travs de la opcin

debug de la lnea de comandos. En realidad es un cliente que hace uso

18


33/242

de las facilidades de depuracin que el intrprete de Javascript que utiliza

Node ofrece a travs de una conexin TCP al puerto 5858. Por tanto, no es

un mdulo que se importe a travs de require()sino el modo de ejecucinDebugdel que se ha hablado antes.

cluster

creacin y gestin de grupos de procesos Node trabajando en red para dis-

tribuir la carga en arquitecturas con procesadores multi-core.

punycode

implementacin del algoritmo Punycode, disponible a partir de la versin

0.6.2, para uso del mdulo url. El algoritmo Punycodese emplea para con-vertir de una manera unvoca y reversible cadenas de caracteres Unicodea

cadenas de caracteres asciicon caracteres compatibles en nombres de red.

El propsito es que los nombres de dominio internacionalizados (en ingls,

IDNA), aquellos con caracteres propios de un pas, se transformen en cade-

nas soportadas globalmente. [10]

domain

mdulo experimental en fase de desarrollo y, por tanto, no cargado por de-

fecto para evitar problemas, aunque los autores de la plataforma aseguranun impacto mnimo. La idea detrs de este l es la de agrupar mltiples

acciones de Entrada/Salida diferentes de tal manera que se dotan de un

contexto definido para manejar los errores que puedan derivarse de ellas [9].

De esta manera el contexto no se pierde e incluso el programa continua su

ejecucin.

Quedan una serie de libreras, que no se mencionan en la documentacin del API

pero que existen en el directorio lib/ del cdigo fuente. Estas libreras tienen

propsitos auxiliares para el resto de los mdulos, aunque se pueden utilizarlas

a travs de require():

_linklist

implementa una lista doblemente enlazada. Esta estructura de datos se em-

plea en timers.js, el mdulo que provee funcionalidad de temporizacin.

Su funcin es encadenar temporizadores que tengan el mismo tiempo de

espera,timeout. Esta es una manera muy eficiente de manejar enormes can-

tidades de temporizadores que se activan por inactividad, como los timeouts

de los sockets, en los que se reinicia el contador si se detecta actividad en

19


34/242

l. Cuando esto ocurre, el temporizador, que est situado en la cabeza de la

lista, se pone a la cola y se recalcula el tiempo en que debe expirar el primero

[11].

buffer_ieee754

implementa la lectura y escritura de nmeros en formato de coma flotante

segn el estndar IEEE754 del IEEE16 que el mdulo bufferemplea para las

operaciones con DoublesyFloats.

constants

todas las constantes posibles disponibles de la plataforma como, por ejem-

plo, las relacionadas con POSIX para seales del sistema operativo y modosde manejo de ficheros. Slo realiza un bindingcon node_constants.cc.

freelist

proporciona una sencilla estructura de poolo conjunto de objetos de la mis-

ma clase (de hecho, el constructor de los mismos es un argumento necesa-

rio). Su utilidad se pone de manifiesto en el mdulo http, donde se mantiene

un conjunto de parsersHTTP reutilizables, que se encargan de procesar las

peticiones HTTP que recibe un Servidor.

sys

es un mdulo deprecado, en su lugar se debe emplear el mdulo utils.

Todos los mdulos anteriores, una vez se ha compilado la plataforma, quedan

incorporados dentro del binario ejecutable, por lo que, fsicamente por su nombre

de archivo no son localizables en disco. Por otra parte, si en disco hubiera un

mdulo cuyo identificador, segn CommonJS, coincidiera con el de algn mdulo

del ncleo, el mdulo que se cargara sera el contenido en el binario de Node, o

sea, el mdulo del core.

2.2.4. Mdulos de terceras partes

Node, adems de por las caractersticas que se estn desgranando, es una gran

plataforma de desarrollo por el inmenso ecosistema que ha crecido en torno suyo.

Se pueden encontrar infinidad de mdulos desarrollados por terceras partes para

usar en proyectos propios, o desarrollar libreras con un propsito especfico,

tanto para uso propietario como para uso de la comunidad Node.

16IEEE: Institute of Electrical and Electronics Engineers

20


35/242

A la hora de utilizar mdulos de terceras partes, se debe ser capaz de especificar

su ubicacin para cargarlos o saber dnde Node va a buscarlos para instalarlos.

Cuando se indica, a travs de la funcin del estndarCommonJS, que un mdu-lo es necesario, el orden que sigue Node para resolver la ruta del fichero hasta

encontrarlo es:

1. Cargar el fichero de nombre igual que el identificador del mdulo, modulo.

2. Si no lo encuentra, le aadir la extensin .js y buscarmodulo.js que

interpretar como un fichero de cdigo JavaScript.

3. Si tampoco lo encuentra, le aadir la extensin .json y buscar

modulo.json e interpretar el contenido como un objeto en notacin

JavaScript (JSON).

4. Por ltimo, buscarmodulo.node e intentar cargarlo como cdigo C/C++

compilado, a travs del mtodo process.dlopen()comentado con anterio-

ridad.

5. Si el identificador del mdulo fuese un directorio, por ejemplomodulo/, Node

buscar el archivo modulo/package.jsonque contiene informacin de cul

es el punto de entrada a la librera. De no hallarlo, intentara resolver dichopunto se ha descrito antes, primero buscando modulo/index.js y, de no

encontrarlo, buscando modulo/index.node.

Determinar la ruta dentro del sistema de ficheros de la mquina donde se halla

el fichero depende de si el identificador de mdulo comienza por:

/ se est referenciando una ruta absoluta en el sistema, con lo que el car-

gador empezar a buscar desde la raz del sistema de archivos del sistema

operativo

./o ../la referencia es a una ruta relativa al directorio donde se encuentra

el mdulo

si el identificador no comienza con las barras, ni es un mdulo del core, Node

lo buscar en el directorio node_modules/que lo supone al mismo nivel en

el rbol de directorios que el fichero de cdigo que requiere al mdulo. Si no

lo encuentra ah, ir buscndolo en todos los directorios padres hasta llegar

al directorio raz del sistema de ficheros. El propsito de ello es localizar las

dependencias de una aplicacin para que no colisionen.

21


36/242

Por ltimo, existen unas variables de entorno desde donde Node buscar libreras

en caso de que todo lo anterior falle. Por ejemplo, desde la ubicacin que indique

NODE_PATH. No obstante, este mtodo se desaconseja totalmente por haber que-dado obsoleto, con lo que no se le va a dar mayor importancia.

2.3. Construida encima del entorno de ejecucin de Ja-

vaScript de Chrome

2.3.1. El lenguaje JavaScript

El lenguaje de programacin que se usa en Node es Javascript. Javascript es un

dialecto de la especificacin estndar ECMA-262 [12]. El uso mayoritario ha esta-

do en el llamado lado del cliente, en referencia a la arquitectura cliente-servidor,

para la capa de presentacin de las aplicaciones web, ntimamente ligado con el

DOM (Document Object Model) [13] que es la interfaz de programacin estndar

para acceder y manipular el contenido, la estructura y el estilo de los compo-

nentes de una pgina web con los que JavaScript interacta en el Navegador

proporcionando una experiencia interactiva al usuario.

Es un lenguaje que se caracteriza principalmente porque es:[14]

interpretado: est diseado para que una capa intermedia de software, el in-

trprete, lo ejecute, en contraposicin a los lenguajes compilados, que corren

directamente sobre la arquitectura y sistema operativo objetivo (por regla

general, ya que Java es compilado pero se ejecuta dentro de una mquina

virtual)

dinmico: ligado con la caracterstica anterior, realiza acciones que en otro

tipo de lenguajes se haran en tiempo de compilacin, como evaluacin de

cdigo, o eval, que es la interpretacin de cdigo en tiempo de ejecucin, o

como la modificacin, tambin en tiempo de ejecucin, de las caractersticas

de las clases o el tipo de las variables

funcional: la programacin funcional es un paradigma de programacin que

se basa en la evaluacin de expresiones, como son las funciones, evitando

tener estados y datos mutables, a diferencia de la programacin imperativa

que se basa en cambios de estado a travs de la ejecucin de instrucciones

22


37/242

[15]. JavaScript posee caractersticas de la programacin funcional como

son las Funciones de Orden Superior. Se denominan as a las funciones que

admiten por parmetro otras funciones o que como resultado devuelven unafuncin.

orientado a objetos parcialmente (o basado en objetos): de los tres requisi-

tos bsicos que definen este tipo de programacin, JavaScript no soporta

el polimorfismo y la encapsulacin slo es posible para funciones dentro

de funciones (las funciones de orden superior antes mencionadas), aunque

posee un modelo de herencia por prototipado.

dbilmente tipado: se realiza una conversin, ocast, del tipo de las variables

en tiempo de ejecucin, segn el uso que se hace de ellas.

JavaScript encaja perfectamente en el paradigma de la programacin orientada a

eventos, en la que el flujo del programa no es secuencial sino que depende de los

eventos, asncronos en su mayora por naturaleza, que se producen durante la

ejecucin del mismo. Las caractersticas funcionales del lenguaje de las que he-

mos hablado son tiles en este paradigma. Las funciones de primer orden hacen

posible el uso de:

funciones annimas: son las funciones que se pasan como parmetro a las

funciones de orden superior. Son tiles para usarlas como callback, asig-

nndolas por parmetro a algn objeto mediante el mtodo correspondiente.

Los callbacksson funciones que se ejecutan como respuesta a un evento.

closures, o cierres: se generan cuando una variable queda referenciada fuera

de su scopea travs, por ejemplo, de una funcin devuelta por otra funcin

de orden superior. Se emplean en callbackspara hacer referencia ascopes

que de otra manera se perderan.[16]

Al ser un lenguaje interpretado, Javascript requiere de un intrprete o mquina

virtual que lo ejecute. En la actualidad hay varios de estos intrpretes disponibles,

por ejemplo: SpiderMonkey de Mozilla, Nitro de Apple o V8 de Google.

SpiderMonkey y V8 fueron diseados para servir como motor Javascript de los

navegadores web Mozilla Firefox y Google Chrome respectivamente. Pero, a dife-

rencia del motor Nitro para Webkit, pueden ser embebidos en otras aplicaciones,

como es este caso.

23


38/242

2.3.2. El motor V8 de Google

La eleccin del motor V8 de Google para Node se debi a que ambos proyectoscomenzaron prcticamente a la vez[3] y, en palabras del autor de Node, V8 es

una buena, organizada librera. Es compacta e independiente de Chrome. Se dis-

tribuye en su propio paquete, es fcil de compilar y tiene un buen archivo header

con una buena documentacin. No tiene dependencia de ms cosas. Parece ms

moderna que la de Mozilla[17]. Adems este motor presenta unas caractersticas

revolucionarias a la hora de interpretar JavaScript.

Para realizar una comparativa entre los diferentes motores JavaScript se pueden

ejecutar los test de benchmarking [18]diseados para probar V8. Estas pruebas

evalan el rendimiento en operaciones matemticas complejas, como criptografa,

o una simulacin de kernel de sistema operativo entre otros muchos, y se ejecutan

sobre el motor presente en el navegador.

V8 es de cdigo abierto, bajo licencia New BSD[19], y est escrito en C++. Im-

plementa la 5a edicin del estndar ECMA-262 y es multiplataforma, lo que ha

permitido a Node estar presente en sistemas tipo Unix (estndar POSIX), Mac y,

a partir de la versin 0.6, en Windows [20].

Dos de las caractersticas principales de V8, que lo han hecho destacar sobre el

resto de motores, son:

compilacin y ejecucin de cdigo JavaScript: el cdigo fuente se pasa cdigo

mquina cuando es cargado y antes de ser ejecutado por primera vez.

recoleccin eficiente de basura: este trmino se utiliza al hablar de la libera-

cin de memoria que ocupan los objetos JavaScript cuando no van a usar-

se ms. V8 emplea un recolectorstop-the-world, es decir, V8, cclicamente,

detiene la ejecucin del programa (en la llamada pausa embarazosa) pro-

cesando slo una parte de la memoria heap para minimizar el efecto de la

parada. Durante esta parada no se crean nuevos objetos pero tambin se

evita con ella que no haya indisponibilidad momentnea de los existentes

[21].

V8 permite a cualquier aplicacin C++ que lo use hacer disponibles sus objetos

y funciones al cdigo JavaScript que ejecuta. Un claro ejemplo de esto es el ya

comentado objeto process disponible en el scopeglobal de cualquier programa

para Node.

24


39/242

Todo el cdigo JavaScript que corre en Node, tanto el de su ncleo como el de

programa, se ejecuta en un nico contexto que se crea cuando se inicia la plata-

forma. Para V8, los Contextos son entornos de ejecucin separados y sin relacinque permiten que se ejecuten varias aplicaciones JavaScript, una en cada Con-

texto, en una nica instancia del intrprete [22]. En el caso de Node, como se ha

comentado, slo hay uno y slo una instancia de V8 por lo que nicamente se

ejecuta un programa a la vez. Si se desea ejecutar ms de un script de Node, se

deben levantar ms instancias.

El hecho de que la plataforma ejecute una sola instancia de V8 induce a pensar

que en mquinas con procesadores de mltiples cores, todos menos uno queda-

rn desaprovechados. Para paliar esta deficiencia existe un mdulo, cluster, an

en estado experimental, que permite lanzar una red de procesos Node, en el que

uno de ellos hace de maestro (master) y el resto de trabajadores (workers). El rol

de maestro es el de vigilar que los procesos trabajadores ejecuten su tarea, que

ser la misma en todos, incluso compartiendo puertos TCP (a diferencia de si se

lanzasen los procesos mediante el mdulo child_process). Un error en alguno de

los workers que lo lleve a detenerse generar un evento death que puede ser

recogido por el maestro para proceder conforme est programado. Por supuesto,

entre los procesos puede haber comunicacin a travs de mensajes, con la mismaAPI que se emplea en el mdulo child_process.

2.4. Fcil desarrollo de rpidas, escalables aplicaciones

de red

Una ventaja de emplear JavaScript como lenguaje para las aplicaciones en Node

es que, al ser un lenguaje con una curva de aprendizaje pronunciada, es decir, quesus fundamentos bsicos se aprenden fcilmente, es posible empezar a desarro-

llar aplicaciones rpidamente con slo tener unas nociones de las caractersticas

fundamentales del lenguaje y conocer el grueso de las libreras del ncleo de la

plataforma.

Un ejemplo muy tpico, y que aparece en la pgina web de Node, es un sencillo

servidor HTTP que responde a las peticiones con un Hello World en tan slo

cinco lneas de cdigo:

var http = require(http);

25


40/242

http.createServer(function (req, res) {

res.writeHead(200, {Content-Type: text/plain});

res.end(Hello World\n);

}).listen(1337, "127.0.0.1");

console.log(Server running at http://127.0.0.1:1337/);

En el cdigo anterior se puede apreciar lo comentado:

el uso de require(http) segn CommonJS para indicar que se usa el

mdulohttp

el uso de funciones de ese mdulo para tratar con servidores web y peticiones

HTTP

una de las caractersticas fundamentales de JavaScript relacionada con su

orientacin a eventos: elcallback, que es la funcin que se pasa como par-

metro acreateServer()y que se ejecutar cada vez que el servidor reciba

una peticin HTTP

Este trozo de cdigo se ha usado para realizar pruebas de rendimiento y compa-

rativas frente a otras tecnologas para usos similares que emplean otra aproxi-

macin (por ejemplo,multithreading) para tratar con los problemas asociados a laescalabilidad de aplicaciones.

Cuando se habla de escalabilidad caben dos perspectivas sobre el tema:

escalabilidad horizontal: aquella en la que, idealmente, el rendimiento crece

linealmente con la adicin de nodos al sistema. En este caso, se tendra un

conjunto de mquinas, cada una de ellas ejecutando Node de manera sin-

cronizada con el resto. En la prctica Node no incorpora caractersticas que

permitan realizar esto de una manera concreta e integrada con su arquitec-tura pero esto no implica que no sea posible, siempre que lo desarrolle el

programador.

escalabilidad vertical: en la que se busca un aumento, tambin lineal ideal-

mente, de rendimiento aadiendo recursos a un solo nodo, donde corre el

sistema. Los recursos principales son la CPU, memoria, disco y red donde

a Node puede exigrsele un poco ms[23]. Pero la puesta a punto de estos

recursos es slo una parte para obtener el mximo rendimiento.

Una de los aspectos con mayor impacto en la escalabilidad es el diseo del sis-

26


41/242

tema. ste es uno de los puntos fuertes de Node. Su arquitectura y la forma en

que las aplicaciones deben programarse para correr en ella hacen que se cumplan

principios bsicos del buen diseo para la escalabilidad [24], un par de ejemplosde esto son:

Sin esperas: el tiempo que un proceso espera a que un recurso est dispo-

nible es tiempo que otro proceso no emplea para ejecutarse. La naturaleza

asncrona y monoproceso de Node aseguran que se optimizar el tiempo de

ejecucin de ambas tareas.

Lucha por los recursos: Node gestiona internamente de manera eficiente los

recursos del sistema para que todas las operaciones sobre, por ejemplo, redo ficheros que se demandan en el cdigo estn satisfechas sin que se abuse

de ellas. As se evita un uso descompensado de las mismas por las distintas

partes del cdigo de la aplicacin.

No obstante, la escalabilidad real de Node est todava por verse [25].

2.5. Usa E/S no bloqueante dirigida por eventos

Uno de los puntos crticos, usual cuello de botella, que afecta en alto grado al

rendimiento de cualquier sistema, en especial a aquellos que hacen un uso in-

tensivo de datos, ya sea mediante fichero, bases de datos o conexiones a travs

de una red, son las operaciones de Entrada/Salida con ficheros y dispositivos.

Habitualmente, en las presentaciones de Node que su autor emplea para dar a

conocer la plataforma, se justifica el diseo de la arquitectura con unas medidas

sobre el impacto que tiene la interaccin de un sistema normal con las distintas

fuentes de datos en trminos de latencia y ciclos de reloj de la CPU. En concreto,se manejan las cifras siguientes[26]:

cach L1: 3 ciclos

cach L2: 14 ciclos

RAM: 250 ciclos

disco: 41.000.000 ciclos

red: 240.000.000 ciclos

Las latencias correspondientes a las cachs del procesador y la memoria RAM son

muy bajas, pero se puede considerar que las de disco y red poseen un retardo

27


42/242

excepcionalmente alto que deja al procesador desocupado. La reaccin habitual

a estos ciclos muertos, en el sentido de actividad de un programa tpico, es,

simplemente, la espera a que la operacin termine para continuar con la ejecucinde las siguientes instrucciones. Es lo que se conoce como sistemas bloqueantes:

durante los ciclos de Entrada/Salida el programa se queda bloqueado en esa

tarea.

A nivel de aplicacin, el ejemplo comn, utilizado tambin en las presentaciones

sobre Node, es la peticin tpica a una base de datos:

result = query(select * from table);

//utilizar result

donde no se podr utilizar el resultado de la peticin hasta que no se haya com-

pletado. Consecuentemente, se bloquea el proceso entero.

2.5.1. El modelo de Concurrencia de Node

La solucin que plantea el autor de Node es un modelo de concurrencia basado

en eventos. En este modelo de concurrencia el flujo del programa viene determi-nado por la reaccin del programa a diversos eventos, en su mayora asncronos.

Las implicaciones que conlleva el uso de un modelo de estas caractersticas son

varias:

la necesidad de un bucle de procesado de eventos. ste se ejecutar en un

nico proceso y, lo que es ms importante, slo ejecutar un manejador de

eventos, o callback, a la vez. De esto se desprende que no se debe de ningu-

na manera realizar operaciones especialmente complejas en ese manejador,

que supongan un gran uso de CPU o sean de larga duracin puesto queel bucle dejar de atender los siguientes eventos que se produzcan con la

consecuente degradacin del programa.

el uso de un lenguaje que encaje en el modelo basado en eventos. En este

caso, JavaScript es la opcin ideal pues el intrprete de este lenguaje se basa

en un modelo idntico.

La consecuencia ms relevante de esto es que el sistema resultante es no blo-

queante: durante los ciclos de Entrada/Salida, el programa realiza las siguientes

tareas hasta que se hayan completado dichos ciclos lo cual ser notificado con

28


43/242

un evento que desencadenar la ejecucin del callback, cuyo cdigo modela la

siguiente tarea a realizar una vez se dispone del resultado de las operaciones

Entrada/Salida.

Nuevamente, a nivel de aplicacin, esta vez el cdigo tendra el aspecto que si-

gue:

query(select * from table, function(result){

//utilizar result

});

donde despus de la llamada a query() se retorna de inmediato al bucle de

eventos para seguir con la ejecucin del programa. Una vez se haya completado

la peticin a la base de datos, se ejecutar la funcin de callbacken la que se

puede utilizar el resultado de la llamada.

2.5.2. Arquitectura de Node

Implementando este modelo se cumple uno de los objetivos de diseo [26]de Node

que es que ninguna funcin debe realizar Entrada/Salida directamente. Nodedelega todas estas operaciones a mecanismos del sistema operativo a travs de

la librera libuv [27], desarrollada especficamente para la arquitectura de Node

[28]. Libuvsurge cuando se porta la plataforma a Windows y el propsito es el

de abstraer todo el cdigo que sea dependiente de una plataforma especfica (*ni-

x/Windows), en concreto aquel referente a la gestin de eventos y operaciones

Entrada/Salida no bloqueantes.

En versiones de Node previas, hasta la 0.6, en los sistemas *nix aquella fun-

cionalidad resida en las libreras libev y libeio respectivamente, y en sistemasWindows, en IOCP. Con la versin 0.6 se introdujo libuvque implementaba para

Windows la funcionalidad que antes corresponda a IOCP, aunque para *nix se-

gua teniendo debajo a libev y libeio. Con la versin 0.8 de la plataforma, libuv

asume las funciones de las dos libreras para todos los sistemas operativos.

Para entender qu funciones asume libuvse debe conocer qu papel desempea-

ban las dos libreras que originariamente formaban parte de Node:

Libev, en palabras de sus creadores, es un bucle de eventos en el que se

registran los denominados event watchersque indican qu eventos debe el

29


44/242

bucle gestionar y cmo debe reaccionar ante ellos, vacallback. Los eventos

son de muchos tipos, desde que un descriptor, como un fichero o un socket,

puede comenzar a leerse hasta que se ha producido un timeout. Node depor s, al arranque, registra muy pocos watchers17, tan slo los referentes

al recolector de basura y aquel que se encarga de la ejecucin de funciones

postpuestas para la siguiente iteracin del bucle [11].

Por su parte,libeioprovee los mecanismos de Entrada/Salida asncrona pa-

ra conseguir programas completamente no bloqueantes. Ofrece versiones

asncronas de la mayora de funciones del estndar POSIX para manejo de

ficheros, que es para lo que se utiliza en Node quedando la Entrada/Salida

de red gestionada por libev. Internamente, emplea un pool de threads [29]

que, por la naturaleza de Node, es transparente para el programador y por

tanto, no hacen que Node seamultithreadeda nivel de sistema, no de aplica-

cin. Adems se integra a la perfeccin en cualquier bucle de eventos, como

por ejemplo con el que proporcionalibuv[30].

El ltimo paso al inicio de Node es la llamada a la funcin que arranca el bucle de

eventos. En este punto ya tenemos cargado en el Contexto todo el cdigo JavaS-

cript, tanto del ncleo (bootstrap) como propio, donde se han definido ante qu

eventos reacciona el programa y el comportamiento ante ellos a travs de funcio-

nes de callback. La misin del bucle es esperar a que stos ocurran y ejecutar el

cdigo que modela dicho comportamiento.

Desde que se define uncallbackcomo respuesta a alguna operacin de Entrada/-

Salida, hasta que dicho callbackentra en ejecucin, en Node se siguen una serie

de pasos:

1. se carga el mdulo que a su vez carga el bindingcorrespondientes

2. se instancia la clase que provee el binding, disponible a travs de V8, a la

que se le instalan los callbacks.

3. el bindingescuchar los eventos que se produzcan en las operaciones de

Entrada/Salida

4. si hay un callback instalado, el binding lo ejecutar a travs de

MakeCallback(), una funcin interna de node.cc para ejecutar cdigo

JavaScript desde cdigo C.

17node.cchttps://github.com/joyent/node/blob/v0.8.20-release/src/node.cc#L2820

30
https://github.com/joyent/node/blob/v0.8.20-release/src/node.cc#L2820https://github.com/joyent/node/blob/v0.8.20-release/src/node.cc#L2820


45/242

Los bindingsson la manera que tiene el cdigo en JavaScript de los mdulos del

core de hacer uso del cdigo nativo [31]. Un binding es un mdulo escrito en

C/C++ que es capaz de utilizar las libreras, por ejemplo libevylibeio, a travs delibuv, para interactuar con el bucle de eventos y la Entrada/Salida directamente,

que es algo que el cdigo JavaScript no puede hacer. Se podra decir que es una

librera a bajo nivel. El bindinga su vez proveer una serie funciones al mdulo

para que ste ofrezca en su exports al desarrollador de aplicaciones su funcio-

nalidad. Por ejemplo, los siguientes bindingsse emplean en las libreras del core

de Node:

buffer

Soporte de codificacin en diferentes sistemas y manejo de datos binarios a

bajo nivel.

Se usa en el mdulo buffer.js

cares_wrap

Consultas asncronas a DNS a travs de la librera cares de la que Node

depende.

Se usa en el mdulo dns.js

constants

Exposicin directa de las constantes posibles de la plataforma.

Se usa en los mdulos child_process.js, constants.js, fs.js

crypto

Capacidades criptogrficas y de cifrado a travs de la librera openSSL.

Se usa en los mdulos crypto.js, tls.js

evals

Acceso a funcionalidad de mquina virtual V8 sobre la manipulacin de Con-

textos para la evaluacin de scripts con cdigo JavaScript. De ah el nombre

del mdulo, node_script.cc.

Se usa en los mdulos module.js, vm.js

fs

Operaciones propias del sistema de ficheros, no operaciones con ficheros

como el nombre del cdigo fuente del mdulo podra indicar (node_file.cc).

31


46/242

Entre otras: manejo de directorios o cambio de permisos.

Se usa en los mdulos fs.js, path.js

fs_event_wrap

Modela la clase evento de sistema de archivos que se emplea para notificar

cambios o errores en el mismo.

Se usa en el mdulo fs.js

http_parser

Usado en conjunto con la dependenciahttp_parser de Node, que extrae

del mensaje HTTP toda la informacin relevante. Sirve de capa intermediaentre sta y el cdigo JavaScript realizando principalmente la gestin de los

callbacks.

Se usa en los mdulos http.js, querystring.js

natives

Contiene el cdigo fuente de todas las libreras del core de Node. El cdigo

fuente del mdulo se genera en tiempo de compilacin por lo que no se

hallar en disco.

Se usa en el mdulo _debugger.js

os

Funciones de recogida de informacin sobre el sistema operativo directa-

mente expuestas a os.js.

Se usa en el mdulo os.js

pipe_wrapCapacidades de comunicacin con procesos y con streamsde TCP.

Se usa en los mdulos child_process.js, net.js

process_wrap

Mtodos spawn y kill para el manejo de procesos.

Se usa en el mdulo child_process.js

tcp_wrap

Manejo de conexiones TCP y su streamasociado.

32


47/242

Se usa en el mdulo net.js

timer_wrapFunciones bsicas para el manejo de un timer: start, stop, again...

Se usa en el mdulo timers.js

tty_wrap

Integracin con el terminal de libuv.

Se usa en el mdulo tty.js

udp_wrap

Manejo de UDP.

Se usa en el mdulo dgram.js

zlib

Integracin del proceso de compresin y/o descompresin en el thread pool

de libuv.

Se usa en el mdulo zlib.js

Un mdulo cargar un bindinggracias a la funcin binding() del objeto process.

Esta funcin se pens para uso interno de Node, pero es accesible al programa-

dor. Se podran desarrollar mdulos para sustituir a los existentes, si se quisiera

o se tuviera la necesidad y conocimientos suficientes.

Cuando un binding se carga, su nombre aparece en la lista de mdulos car-

gados moduleLoadList del objeto process precedido de la palabra Bindingpa-

ra diferenciarlo de los mdulos JavaScript, a cuyo nombre precede la palabra

NativeModule.

2.5.3. La clase EventEmitter

Pero la Entrada/Salida no es la nica manera que existe en Node de que se pro-

duzcan eventos. Se puede dotar a cualquier clase de la habilidad de emitirlos

gracias a la claseEventEmitterque el mdulo eventsfacilita y de la que se pueden

heredar sus mtodos empleando la funcin inherits() del mdulo utils. Esta

parte no hace uso del bucle de eventos, y se produce a nivel de cdigo JavaScript

[32].

33


48/242

Bsicamente, al proporcionar a una clase mtodos para la gestin de eventos, se

facilita que:

la clase d la oportunidad a otras clases de escuchar sus eventos subs-

cribindose a ellos a travs de mtodos como on() o addListener(), en

desuso a favor del anterior. Se puede hacer incluso que un subscriptor es-

cuche un evento una sola vez con once(). Es importante indicar que, para

evitar posibles prdidas de memoria, la clase avisa por consola de que se

ha superado el lmite de 10 subscriptores, aunque permite tenerlos. Sin em-

bargo, como no todas las clases pueden tener esa limitacin, se ofrece la

posibilidad de aumentarlo siempre que, explcitamente, se fije con una lla-

mada asetMaxListeners()

la clase d la oportunidad a sus subscriptores de dejar de atender a los

eventos que escuchan con removeListener(). Incluso se pueden eliminar

todos con removeAllListeners()

por supuesto, la clase disponga de un mecanismo para emitir los even-

tos cuando el programador lo crea conveniente. Este mtodo es la funcin

emit()a la que se le indica qu tipo de evento se genera. emit()hace uso

del objeto _events, propiedad de EventEmitter, en el que cada propiedadtiene el nombre de un evento y el valor asociado a stas es un array de

callbacksinstalados por los subscriptores. Por ejemplo:

_events = {

"connect": [function(){}, function(){}],

"customEvent": [function(){}, function(){}],

//si solo hay un subscriptor no se mete en un array

"newListener": function(){}

}

2.5.4. Postponiendo la ejecucin de funciones

Adems de todo lo comentado se dispone de una ltima forma de interactuar

con el bucle de eventos. Se puede programar la ejecucin de una funcin en la si-

guiente iteracin del bucle pasndosela como argumento a la funcinnextTick()

del objeto process, que es el mecanismo que Node proporciona con tal propsi-

to.

34


49/242

process.nextTick()se define en el proceso de bootstrapde node.js 18.A travs

de ella se podrn encolar una o ms funciones en nextTi

Introduccion a Nodejs a Traves de Koans eBook

Documents

Transcript of Introduccion a Nodejs a Traves de Koans eBook