Universidad​ ​Politécnica​ ​de​ ​Sinaloa

Ingeniería​ ​en​ ​Informática

“Desarrollo​ ​de​ ​aplicaciones​ ​web​ ​con

[Link]”

Autor:
Jesús​ ​Octavio​ ​Guardado​ ​Osuna
Asesora:
Patricia​ ​Guadalupe​ ​Torrero​ ​Martinez
Lugar​ ​y​ ​fecha​ ​de​ ​entrega:
Mazatlán,​ ​Sinaloa​ ​ ​15​ ​de​ ​Diciembre​ ​de​ ​2017
Dedicatoria.
Dedico este documento a mis padres, un par de excelentes personas que a lo largo
de mi vida me han enseñado a trabajar duro para poder cumplir mis metas y me han
dado apoyo moral siempre que lo necesito, es gracias a ellos que he llegado hasta
aquí, y con sus consejos y enseñanzas espero llegar aún más lejos. A pesar de que
constantemente me repiten que debo hacer lo que me haga feliz, y no lo que haga
feliz a otros, espero que la exitosa finalización de mi carrera universitaria en la
Universidad​ ​Politécnica​ ​de​ ​Sinaloa​ ​los​ ​haga​ ​felices​ ​tanto​ ​como​ ​a​ ​mi​ ​me​ ​hace​ ​feliz.
Agradecimientos.
Quiero utilizar este medio para agradecer a los maestros de mi alma mater, quienes
mediante su ardua labor hacen de esta institución una de las mejores de Mazatlán,
competente incluso al ser comparada con instituciones de paga, y es gracias a ellos
que el interés que tengo por esta carrera creció a lo largo de mis años de estudio
universitario. Quiero agradecer de la misma manera a mis padres por su
incondicional apoyo, y a mi abuelo Jesús Guardado quien apoyó a mis padres
económicamente pagando por mis estudios cuando nos encontrábamos en tiempos
difíciles.
Resumen.
En esta tesina se pretende explicar el estado actual del desarrollo de aplicaciones
web con la herramienta [Link] y las herramientas y frameworks más populares que
han surgido en torno a [Link], así como analizar su uso actual por compañías
grandes, así como su uso para proyectos medianos y chicos. Se pretende también
analizar su popularidad pasada y presente para así hacer una predicción de su
popularidad​ ​futura​ ​y​ ​su​ ​rol​ ​en​ ​el​ ​mundo​ ​de​ ​las​ ​herramientas​ ​para​ ​el​ ​desarrollo​ ​web.

Abstract.
The objective of this thesis is to explain the current state of web applications
development with the tool [Link] and the most popular tools and frameworks that
have emerged around [Link], and to analyze its use by big companies, but also its
use for medium and small projects. Another objective is to analyze its past and
present popularity to be able to make a prediction of its future popularity and its role
in​ ​the​ ​world​ ​of​ ​web​ ​development​ ​tools.
Índice​ ​General.
CAPÍTULO​ ​I.​ ​INTRODUCCIÓN​ ​…………………………………………………………​ ​ ​1

Introducción​ ​…………..…………………………………………………………..​ ​ ​1

Antecedentes​ ​……………………………………………………………………..​ ​ ​3

Planteamiento​ ​del​ ​Problema​ ​…………………………………………………...​ ​ ​6

Hipótesis​ ​……………………………………………………………………………​ ​7

Objetivos​ ​……………………………………………………………………………​ ​8

Importancia​ ​y/o​ ​Justificación​ ​del​ ​Estudio​ ​…………………………………….​ ​9

Limitaciones​ ​del​ ​Estudio​ ​……………………………………………………….​ ​10

Definición​ ​de​ ​términos​ ​………………………………………………………….​ ​11

CAPÍTULO​ ​II.​ ​MARCO​ ​REFERENCIAL​ ​Y​ ​MARCO​ ​TEÓRICO​​ ​……………………..​ ​12

Introducción​ ​………………………………………………………………………​ ​12

Descripción​ ​y​ ​Análisis​ ​de​ ​investigaciones​ ​relacionadas​​ ​………………...​ ​13

Sumario​ ​…………………………………………………………………………….​ ​32

CAPÍTULO​ ​III.​ ​METODOLOGÍA​ ​………………………………………………………...​ ​33

Diseño​ ​……………………………………………………………………………...​ ​33

Desarrollo​ ​...……………………………………………………………………….​ ​41

CAPÍTULO IV. RESULTADOS …………………………………………………………..

43

Introducción​ ​………………………………………………………………………​ ​43

Análisis​ ​de​ ​Datos​ ​………………………………………………………………...​ ​44

CAPÍTULO V. DISCUSIÓN ……………………………………………………………....

57

Conclusiones​ ​……………………………………………………………………..​ ​57

Referencias​ ​bibliográficas​ ​……………………………………………………………..​ ​60
Glosario​ ​……………………………………………………………………………………​ ​61

Índice​ ​de​ ​imágenes.

1.0​ ​Compañías​ ​que​ ​actualmente​ ​utilizan​ ​[Link]​ ​………………………………….​ ​21

1.1​ ​Áreas​ ​en​ ​las​ ​que​ ​las​ ​compañías​ ​utilizan​ ​[Link]​ ​……………………………...​ ​22

1.2​ ​Tecnologías​ ​que​ ​se​ ​utilizan​ ​en​ ​conjunto​ ​con​ ​[Link]​ ​………………………..​ ​23

1.3​ ​Tipos​ ​de​ ​desarrollo​ ​con​ ​[Link]​ ​………………………………………………….​ ​24

1.4​ ​Sistemas​ ​operativos​ ​utilizados​ ​para​ ​desarrollar​ ​aplicaciones​ ​con​ ​[Link]​ ​25

1.5​ ​Mejoras​ ​que​ ​han​ ​notado​ ​los​ ​desarrolladores​ ​encuestados​ ​al​ ​usar​ ​[Link]​ ​27

1.6​ ​Aumento​ ​de​ ​popularidad​ ​por​ ​región​ ​en​ ​este​ ​año​ ​……………………………..​ ​28

1.7​ ​Alcance​ ​global​ ​de​ ​[Link]​ ​…………………………………………………………​ ​29

1.8​ ​Facilidad​ ​de​ ​aprendizaje​ ​de​ ​[Link]​ ​……………………………………………..​ ​30

1.9​ ​Nivel​ ​de​ ​involucración​ ​de​ ​los​ ​usuarios​ ​………………………………………….​ ​31

2.0​ ​Llamada​ ​al​ ​sistema​ ​(syscall)​ ​………………………………………………………​ ​45

2.1​ ​Diferencias​ ​de​ ​tiempo​ ​entre​ ​llamadas​ ​blocking​ ​y​ ​non-blocking​ ​…………....​ ​46

2.2​ ​Integración​ ​de​ ​PHP​ ​al​ ​sistema​ ​…………………………………………………….​ ​49

2.3​ ​Proceso​ ​del​ ​servidor​ ​de​ ​Java​ ​……………………………………………………..​ ​51

2.4 Modelo I/O de [Link] ………………………………………………………………....

53

2.5​ ​Modelo​ ​I/O​ ​de​ ​Go​ ​…………………………………………………………………….​ ​57

CAPÍTULO​ ​I.​ ​INTRODUCCIÓN

Introducción.
La creciente popularidad de JavaScript ha traído consigo una gran cantidad de
cambios, y hoy en día el desarrollo web se ve completamente diferente a como ha
sido en años anteriores. El poder utilizar JavaScript tanto en el servidor como en
nuestro navegador era algo difícil de imaginar hace menos de una década, o estaba
altamente​ ​limitado​ ​a​ ​ambientes​ ​encapsulados​ ​como​ ​flash​ ​o​ ​Java​ ​Applets.

Uno de los principales beneficios de NodeJs se encuentra en la posibilidad de su

unificación con otras herramientas basadas en JavaScript para poder así crear un
stack completo de JavaScript, es decir, utilizar JavaScript como el único lenguaje de
programación desde la realización de peticiones a la base de datos, hasta su
utilización para la lógica de las vistas en una página web. Es importante también
mencionar el popular formato de datos JSON1 que actualmente se ha convertido en
un estándar para la transferencia de datos para aplicaciones tanto web como
móviles. El utilizar el mismo lenguaje para todo el proceso de desarrollo nos da la
ventaja de la reutilización de recursos humanos, es decir, utilizar a los mismos
desarrolladores para realizar tareas tanto de backend como de frontend, actividad
que representa un problema en el caso de existir 2 o más lenguajes diferentes, ya
que al pasar de una a otra tarea que requiera distintos lenguajes surge confusión y
reducción​ ​de​ ​eficiencia​ ​en​ ​el​ ​desarrollo.

Nodejs es un runtime de JavaScript desarrollado sobre el motor V8 de JavaScript

que se encuentra en los navegadores Chrome, el creador de NodeJs Ryan Dahl
tenía en mente una herramienta para la creación de sitios web con capacidades de
notificaciones push. Con NodeJs provee una herramienta para trabajar bajo un
paradigma​ ​sin​ ​bloqueos​ ​y​ ​basado​ ​en​ ​eventos​ ​de​ ​entrada​ ​y​ ​salida​ ​(I/O).

Esta tecnología es especialmente útil en aplicaciones web de tiempo real que

emplean notificaciones push con tecnologías de websockets. Lo revolucionario de
esta tecnología es que después de tanto tiempo tenemos la posibilidad de desarrollar
con facilidad aplicaciones web en tiempo real con conexión de dos vías, donde tanto
el cliente como el servidor pueden iniciar la comunicación, creando la posibilidad de
un fluido intercambio de datos. En contraste, en los paradigmas de respuestas web
tradicionales​ ​el​ ​cliente​ ​es​ ​siempre​ ​el​ ​que​ ​inicia​ ​la​ ​comunicación.

1
​ ​JSON,​ ​JavaScript​ ​Object​ ​Notation,​ ​formato​ ​de​ ​envío​ ​de​ ​datos​ ​estructurados.
Con todas estas ventajas que nos presenta esta herramienta las compañías grandes
no han tardado en utilizar NodeJs para implementar sus beneficios en su conjunto de
tecnologías. Compañías como Wal-mart y Uber utilizan NodeJs para llevar a cabo el
manejo de su información, estas entre otras empresas que se mencionan más
adelante en la tesina forman parte de los casos de uso que en el futuro servirán
como referencia para que otras compañías puedan ver los beneficios en el uso de
esta​ ​tecnología​ ​y​ ​consideren​ ​su​ ​uso.
Antecedentes.
Marc Andreessen fundador de Netscape Communications y previamente parte del
equipo de Mosaic tuvo la visión de que la web necesitaba una manera de volverse
más dinámica. Animaciones, interacción y otras formas de automatización pequeña
debian de volverse parte integra de la web en un futuro cercano. Por lo tanto, la web
necesitaba​ ​un​ ​lenguaje​ ​de​ ​scripting​ ​el​ ​cual​ ​pudiera​ ​interactuar​ ​con​ ​el​ ​DOM2.

Está decisión fue una estrategia importante en su momento, ya que este lenguaje no
fue pensado para desarrolladores experimentados ni para personas con titulos de
ingenieria en software, estaba pensado para que cualquier persona pudiera escribir
pequeños​ ​scripts​ ​con​ ​el.

Java en ese entonces tenia una creciente popularidad, y Java en el lado del cliente
con los Java applets serian pronto una realidad. De manera que este nuevo lenguaje
de scripting debía de tener una audiencia distinta, los diseñadores. En esos años la
web era estática, HTML aún era joven y era lo suficientemente simple para que
personas sin conocimientos básicos de programación lo utilizaran. Así que teniendo
en cuenta a esta audiencia se decidió que cualquier cosa que se integrara a los
navegadores web para hacerlos más dinámicos debía de estar orientado a
no-programadores.

JavaScript fue inicialmente nombrado Mocha cuando fue desarrollado por Netscape
(Sebastián​ ​Peyrott,​ ​2017)​ ​en​ ​el​ ​año​ ​1996​ ​por​ ​Brendan​ ​Eich.

En Septiembre de 1995 fue lanzada la versión beta del navegador Netscape 2.0 el
cual​ ​incluía​ ​por​ ​primera​ ​vez​ ​Mocha,​ ​que​ ​fue​ ​renombrado​ ​como​ ​“LiveScript”.

En diciembre de 1995 LiveScript fue nuevamente cambiado a JavaScript, nombre

que actualmente conserva. Alrededor de esas fechas Netscape también trabajaba
arduamente en conjunto con Sun, la compañía responsable de crear el lenguaje de
programación Java, lenguaje de extrema popularidad en ese tiempo. La decisión de
utilizar este nombre causó mucha especulación. Muchas personas en aquel
momento pensaron que Netscape intentaba atraer atención a su nuevo lenguaje
utilizando la popularidad de Java. Desafortunadamente para Netscape esta decisión
causó confusión entre los desarrolladores, ya que automáticamente asumieron que
Java y JavaScript estaban relacionados de alguna manera, cuando en realidad estos
lenguajes​ ​tienen​ ​muy​ ​poco​ ​en​ ​común.

2
​ ​DOM:​ ​Document​ ​Object​ ​Model,​ ​en​ ​español​ ​Modelo​ ​de​ ​Objetos​ ​del​ ​Documento​ ​es​ ​un​ ​árbol​ ​de
objetos​ ​html​ ​que​ ​el​ ​navegador​ ​forma​ ​al​ ​cargar​ ​una​ ​pagina​ ​web.
A pesar de la confusión, JavaScript se convirtió rápidamente en un lenguaje de
scripting para el lado del cliente muy popular. Como respuesta al éxito de JavaScript,
Microsoft creó su propia implementación a la cual nombraron JScript, y fue lanzada
por primera vez junto con Internet Explorer 3.0 en agosto de 1996. En noviembre de
1996 Netscape presentó JavaScript a Ecma International, una organización
internacional de estándares para su estandarización. En junio del año 1997
JavaScript​ ​se​ ​convirtió​ ​en​ ​el​ ​estándar​ ​ECMA-2623.

A lo largo de los años, JavaScript se ha mantenido como el estándar de facto para

desarrollo del lado del cliente. Sin embargo, el área del servidor era una historia
completamente diferente. En su mayor parte, el área del servidor ha sido dominado
por lenguajes como PHP y Java. En décadas anteriores se han implementado un
bajo número de proyectos utilizando JavaScript como lenguaje para el servidor pero
ninguno de ellos fue exitoso. El ejemplo más grande de esto es el intento de
Netscape en el año 1996 cuando lo implemento en el ​Netscape Enterprise HTTP
Server, ese fue el primer intento de implementación de JavaScript como lenguaje del
lado del servidor. Existían dos grandes problemas que detenían la adopción en masa
de JavaScript como un lenguaje de servidor. El primer problema era su reputación;
JavaScript por mucho tiempo era visto como un lenguaje “juguete”, lo cual alejaba a
los programadores veteranos. El segundo problema era el desempeño del lenguaje,
el cual comparado con otros lenguajes del lado del servidor dejaba mucho que
desear. En pocas palabras, a JavaScript le faltaba tiempo de maduración para poder
llegar​ ​a​ ​los​ ​servidores.

Sin embargo, JavaScript tenía una ventaja a su favor. La web estaba

experimentando un crecimiento sin precedentes, y con ese crecimiento las guerras
de los navegadores habían comenzado. JavaScript era en ese entonces el único
lenguaje que tenía soporte por todos los navegadores populares, JavaScript
comenzó a recibir mucha atención por parte de Google, Apple y otras compañías.
Toda esa atención llevo a grandes mejoras en su desempeño. En un periodo de
tiempo muy corto JavaScript dejó de ser un lenguaje lento y comenzó a recibir más
atención​ ​por​ ​parte​ ​de​ ​los​ ​desarrolladores.

La comunidad de desarrollo comenzó a notar el potencial que JavaScript estaba

adquiriendo y comenzó a crear aplicaciones interesantes. En 2009 Ryan Dahl creo
[Link] un framework4 utilizado principalmente para la creación de servidores que

3
​ ​ECMA-262,​ ​estandar​ ​de​ ​Ecma​ ​international,​ ​[Link]
4
​ onjunto​ ​estandarizado​ ​de​ ​conceptos,​ ​prácticas,​ ​criterios​ ​y​ ​en​ ​este​ ​caso​ ​también
​ ​Framework,​ c
codigo​ ​para​ ​enfocar​ ​un​ ​tipo​ ​de​ ​problemática​ ​particular​ ​que​ ​sirve​ ​como​ ​referencia,​ ​para​ ​enfrentar​ ​y
resolver​ ​nuevos​ ​problemas​ ​de​ ​índole​ ​similar.
escalan fácilmente con sus aplicaciones web. Dahl fue impulsado por su falta de
satisfacción con la manera en que el servidor Apache Http manejaba las conexiones
concurrentes y la manera en la que el código bloqueaba ejecuciones continuas o
ejecutaba múltiples stacks de ejecución en el caso de conexiones simultáneas.
[Link] o simplemente Node, está escrito en C++ y JavaScript. Para la creación de
Node, Dahl utilizó el motor de JavaScript V8 de Google, el cual es también utilizado
por Google Chrome, uno de los navegadores más populares del mundo. Con V8 los
desarrolladores pueden crear aplicaciones completas de la misma manera que lo
harían con C o Java. Ryan Dahl presentó su proyecto [Link] por primera vez
durante​ ​la​ ​inauguración​ ​de​ ​JSConf​ ​de​ ​Europa​ ​el​ ​8​ ​de​ ​noviembre​ ​de​ ​2009.

Originalmente Ryan Dahl desarrollaba y mantenía el proyecto de Node solo, pero

poco tiempo después fue patrocinado por la empresa de infraestructura en la nube
Joyent, Node siempre ha sido un proyecto open-source, pero la influencia de Joyent
eventualmente llevó a la separación de la comunidad. [Link] fue una copia de [Link]
creada a finales del año 2014, su creador Fedor Induntny tenía la esperanza de que
[Link] no se viera afectado por la influencia de compañías como fue el caso de
[Link] con Joyent manteniéndolo estrictamente bajo la filosofía open source
governance​ ​(gobernancia​ ​de​ ​fuente​ ​abierta).

Poco tiempo después de la creación de [Link] comenzaron fuertes discusiones entre

la comunidad de Node y IO resultando en la fusión de ambos frameworks y la
creación de la “[Link] Foundation” (Fundación [Link]) la cual se mantiene en una
posición neutral, es decir lo más apegada posible a la filosofía open source
governance. Hasta la fecha, La fundación [Link] se encarga del desarrollo y
mantenimiento del proyecto [Link]. [Link] actualmente ya no recibe mantenimiento y
se​ ​ha​ ​integrado​ ​completamente​ ​con​ ​Node.

La fundación [Link] funciona de manera democrática, y es gobernada por un grupo

conocido como el Technical Steering Committee (Comité de manejo técnico), como
puede deducirse por su nombre, este comité se encarga de los aspectos técnicos
que existirán en las siguientes versiones de [Link]. El TSC también se encarga de
evitar que una sola compañía tome control completo del liderazgo del proyecto, son
también capaces de añadir o remover miembros del comité por medio de votaciones.
Se​ ​busca​ ​que​ ​todas​ ​las​ ​objeciones​ ​sean​ ​tomadas​ ​en​ ​cuenta.

En junio del 2010 se introdujo un manejador de paquetes oficial para el ambiente de

[Link] llamado npm. La idea principal de npm es facilitar a los programadores
publicar y compartir código de fuente de librerías para [Link] y para simplificar la
instalación,​ ​desinstalación​ ​y​ ​actualización​ ​de​ ​esas​ ​mismas​ ​librerías.
En junio del 2011, Microsoft junto con Joyent implementaron una versión nativa de
[Link] en Windows, y la primera versión oficial que soportaba el uso de Windows
fue​ ​lanzada​ ​en​ ​julio​ ​del​ ​2011.

En junio del 2012, Dahl salió como líder del proyecto y nombró a su compañero de
trabajo Isaac Schlueter como nuevo líder. En enero de 2014 Schlueter anuncio a
Timothy​ ​J.​ ​Fontaine​ ​como​ ​nuevo​ ​líder.
Planteamiento​ ​del​ ​Problema.
Con la existencia de múltiples herramientas para el desarrollo web surge una
interrogante al contemplar el uso de [Link], ¿Por qué usar una herramienta
relativamente reciente cuando existen herramientas con muchísimo más tiempo de
existencia​ ​y​ ​más​ ​casos​ ​de​ ​usos?

[Link] es una herramienta que responde a una necesidad en particular y entender

esto es esencial para saber cuándo y cómo utilizar Node. [Link] no es una
herramienta para tareas que requieran alto poder de procesamiento, de hecho, este
tipo de tareas no utilizarían las verdaderas ventajas de esta herramienta. Node es
especialmente útil para crear aplicaciones rápidas, escalables y que utilizan
comunicación a través de una red, ya que es capaz de soportar un gran número de
conexiones​ ​simultáneas​ ​con​ ​alto​ ​rendimiento,​ ​lo​ ​cual​ ​se​ ​traduce​ ​a​ ​alta​ ​escalabilidad.

Su funcionamiento interno es bastante interesante. Comparado con técnicas más

tradicionales de web-serving donde cada conexión o petición genera un nuevo
thread genera espacio en la RAM del sistema y eventualmente llenándola hasta su
punto máximo, [Link] opera en un solo thread utilizando llamadas non-blocking I/O
(se explicará a fondo el funcionamiento de estas llamadas más adelante en este
trabajo de investigación), esto permite que el servidor soporte decenas de miles de
conexiones​ ​concurrentes.

Desde los primeros años de creación de [Link] se experimentó con su desempeño,

uno de los cálculos más sobresalientes es el de Michael Abernethy en su artículo
“¿Qué es [Link]?” publicado en el blog de IBM developerWorks en el año 2011, el
cual por desgracia ya no está disponible, es en ese artículo que el autor menciona un
caso teórico en el que se compara un servidor tradicional en el cual un thread está
acompañado de aproximadamente 2 MB de memoria, lo cual en un sistema con 8
GB de memoria RAM nos da un número máximo de 4000 conexiones concurrentes,
además del costo de cambio de contexto entre threads. [Link] evitando el uso de
threads puede llegar hasta tener un millón de conexiones concurrentes, y cerca de
600​ ​mil​ ​conexiones​ ​de​ ​websockets​ ​concurrentes.

Podemos observar que el paradigma de desarrollo non-blocking I/O a pesar de ser

un paradigma que existía previamente en otros lenguajes de programación y existían
aplicaciones utilizando este paradigma no había tenido mucha popularidad. Fue
gracias al rol central del event loop en javascript que se aplicó este paradigma con
tanta facilidad en [Link] y la comunidad de desarrolladores web comenzó a ver el
potencial​ ​de​ ​utilizar​ ​non-blocking​ ​I/O​ ​y​ ​[Link]​ ​para​ ​el​ ​backend​ ​de​ ​sistemas​ ​web.
La mayoría de las aplicaciones tanto web como de escritorio en la actualidad están
escritas con el paradigma contrario al que se acaba de mencionar, es decir, con el
paradigma blocking I/O, lo cual, analizando su desempeño, para ilogico, pero debido
a que se había experimentado poco con el paradigma non-blocking I/O no se
consideraban​ ​otras​ ​opciones.
Hipótesis.
En la actualidad las empresas pueden ver un crecimiento exponencial enorme de
conexiones en sus servidores debido a la popularidad de los dispositivos móviles,
una aplicación puede crecer mucho en número de usuarios en una cantidad de
tiempo muy corta, por lo tanto, es necesario utilizar un conjunto de tecnologías que
puedan​ ​escalar​ ​con​ ​facilidad.

Hipótesis. [Link] y las tecnologías desarrolladas para trabajar en conjunto con

Node son una excelente alternativa a tecnologías actuales para el desarrollo web
debido​ ​a​ ​su​ ​alta​ ​escalabilidad.
Objetivos.
El objetivo de esta tesina es analizar el estado actual de desarrollo web con [Link]
y tecnologías que utilizan el ambiente de Node para su ejecución. De la misma
manera se pretende proponer este conjunto de tecnologías como una alternativa
viable a tecnologías de desarrollo web actuales demostrando sus ventajas pero a la
vez exponiendo sus desventajas y cómo la comunidad de desarrolladores web está
trabajando​ ​en​ ​ellas​ ​para​ ​proveer​ ​una​ ​plataforma​ ​más​ ​estable​ ​en​ ​el​ ​futuro.
Importancia​ ​y/o​ ​Justificación​ ​del​ ​Estudio.
● Justificación.
Este trabajo de investigación generará reflexión en el lector respecto al estado actual
del desarrollo web y las tecnologías que se utilizan actualmente para desarrollar
aplicaciones web y lo hará cuestionar el desempeño actual de los servidores que
utilizan​ ​lenguajes​ ​y​ ​servidores​ ​http​ ​más​ ​tradicionales.

Este trabajo también podrá servir en el futuro como una referencia al estado del
desarrollo web con [Link] en el momento en el que se escribió este documento, y
de​ ​tal​ ​manera​ ​podría​ ​ser​ ​utilizado​ ​como​ ​punto​ ​de​ ​comparación.

Se espera que esta investigación pueda eventualmente llegar a lectores que utilicen
herramientas de desarrollo web tradicionales y puedan ser convencidos de cambiar
su conjunto de herramientas a herramientas que se ejecuten en el ambiente de
desarrollo​ ​de​ ​[Link].

● Importancia.
En cuanto al alcance de esta investigación, se pretende que llegue a ser una
referencia para futuras investigaciones de un carácter similar, e inspire a
desarrolladores​ ​a​ ​utilizar​ ​Node​ ​e​ ​investigar​ ​al​ ​respecto.
Limitaciones​ ​del​ ​Estudio.
La limitación más importante en la realización de esta investigación es conseguir una
amplia cantidad de información, debido a que [Link] y el conjunto de tecnologías
que se expondrán en esta tesina son relativamente nuevas de tal manera que no se
han escrito muchos artículos de investigación ni libros al respecto, sin embargo, el
entusiasmo por parte de la comunidad puede verse en foros y blogs en los cuales se
encuentra mucha información sobre el tema, y los pocos libros existentes del tema
exponen​ ​ampliamente​ ​el​ ​tema​ ​en​ ​cuestión.

Otra limitación puede ser la objetividad de los documentos encontrados en línea, ya

que​ ​pueden​ ​existir​ ​opiniones​ ​muy​ ​divididas​ ​sobre​ ​el​ ​tema.
Definición​ ​de​ ​términos.
API: ​Aplication Programming Interface, Interfaz de Programación de Aplicaciones,
es un conjunto de subrutinas, funciones y procedimientos (o métodos, en la
programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por
otro​ ​software​ ​como​ ​una​ ​capa​ ​de​ ​abstracción.

Blocking: ​Métodos que deben de terminar para que pueda comenzar la ejecución
del​ ​siguiente​ ​método.

Non-blocking: ​Métodos que no bloquean la ejecución de otros o bloquean por una

cantidad​ ​de​ ​tiempo​ ​muy​ ​corta.

I/O:​ ​Input/Output,​ ​operaciones​ ​que​ ​requieren​ ​un​ ​ingreso​ ​o​ ​egreso​ ​de​ ​datos.

Frontend: ​Tipo de programación que involucra la parte del cliente, esté se puede
referir​ ​tanto​ ​a​ ​cliente​ ​móvil​ ​como​ ​web.

Backend: ​Tipo de programación que se refiere a la parte del servidor, es la que se

encarga​ ​de​ ​ejecutar​ ​métodos​ ​de​ ​obtención​ ​y​ ​envío​ ​de​ ​datos.

Big​ ​Data:​ ​Manejo​ ​de​ ​grandes​ ​cantidades​ ​de​ ​datos.

IoT: ​Internet of Things (Internet de las cosas), se refiere a los dispositivos

electrónicos no clasificados como una computadora o celular en el sentido
convencional​ ​que​ ​están​ ​conectados​ ​al​ ​internet.

Analytics:​ ​Análisis​ ​de​ ​datos.

JSON: ​JSON, acrónimo de JavaScript Object Notation, es un formato de texto ligero

para el intercambio de datos. JSON es un subconjunto de la notación literal de
objetos de JavaScript aunque hoy, debido a su amplia adopción como alternativa a
XML,​ ​se​ ​considera​ ​un​ ​formato​ ​de​ ​lenguaje​ ​independiente.

DOM: ​Document Object Model o DOM ('Modelo de Objetos del Documento' o

'Modelo en Objetos para la Representación de Documentos') es esencialmente una
interfaz de plataforma que proporciona un conjunto estándar de objetos para
representar documentos HTML, XHTML y XML, un modelo estándar sobre cómo
pueden combinarse dichos objetos, y una interfaz estándar para acceder a ellos y
manipularlos.

Framework: ​Un framework, entorno de trabajo o marco de trabajo​ es un conjunto

estandarizado de conceptos, prácticas y criterios para enfocar un tipo de
problemática particular que sirve como referencia, para enfrentar y resolver nuevos
problemas​ ​de​ ​índole​ ​similar.

SDK: ​Un kit de desarrollo de software es generalmente un conjunto de herramientas

de desarrollo de software que le permite al programador o desarrollador de software
crear una aplicación informática para un sistema concreto, por ejemplo ciertos
paquetes de software, frameworks, plataformas de hardware, computadoras,
videoconsolas,​ ​sistemas​ ​operativos,​ ​etcétera.
CAPÍTULO​ ​II.​ ​MARCO​ ​REFERENCIAL​ ​Y​ ​MARCO​ ​TEÓRICO.

Introducción.
[Link] es especialmente útil al desarrollar aplicaciones en tiempo real que requieran
de conexión a una red de manera que el cliente y el servidor puedan tener una
comunicación​ ​de​ ​dos​ ​direcciones.

Muchas empresas de talla internacional comenzaron a ver rápidamente el potencial

que tiene [Link] para crear aplicaciones web, y debido a que la mayoría de estas
organizaciones ya contaban con ingenieros con conocimientos de JavaScript fue
realmente rápida la creación de equipos de desarrollo e investigación con Node.
Además, de empresas grandes con años en la industria del desarrollo de software,
también encontramos el caso de empresas como Uber que al comenzar decidieron
apostar por esta tecnología la cual a pesar de tener poco tiempo de creación
presentaba​ ​ventajas​ ​muy​ ​atractivas​ ​que​ ​convencieron​ ​a​ ​los​ ​fundadores​ ​de​ ​startups.
Descripción​ ​y​ ​Análisis​ ​de​ ​investigaciones​ ​relacionadas.

● Soluciones​ ​al​ ​problema​ ​planteado.

Durante los primeros años de existencia de [Link] su adopción fue lenta, la mayor
parte de su uso fue meramente investigativo por parte de desarrolladores,
desarrolladores que pretendían comparar a [Link] con las herramientas que
usaban​ ​en​ ​ese​ ​entonces.

Poco tiempo después su adopción comenzó y por sorpresa no tomó mucho tiempo
para que las empresas de alto calibre vieran el potencial que ofrecía esta nueva
herramienta​ ​y​ ​el​ ​paradigma​ ​que​ ​propone.

○ Microsoft.
Microsoft, empresa que por años ha sido conocida como una empresa en contra del
software libre, sentimiento expresado por Bill Gates en múltiples ocasiones cuando
ocupaba la posición de CEO en Microsoft, está ahora moviéndose a una posición
más aceptante de la comunidad open source y sus productos. En el caso de Node,
Microsoft lo adoptó pocos años después de su creación en 2011 con ayuda de
Joyent, que en ese entonces era la principal donadora al proyecto de [Link], y se
consideraba que tenía un control casi total sobre el desarrollo de la plataforma.
Microsoft le dio soporte a [Link] en sus servidores web de Microsoft de manera que
existiera​ ​un​ ​runtime​ ​estable​ ​en​ ​ambientes​ ​de​ ​producción.

En años recientes, Microsoft ha aumentado aún más su soporte a Node ofreciendo

integración directa a su plataforma Azure. Azure es una plataforma de servicios en
la nube ofrecidos como servicio y alojados en los Centros de datos de Microsoft, esta
plataforma existe desde el 2010, pero fue anunciado desde el 2008, y fue hasta
comienzos del 2016 que Microsoft comenzó a dar soporte a [Link]. Windows Azure
es una plataforma general, por lo tanto, pueden desarrollarse todo tipo de
aplicaciones​ ​que​ ​requieran​ ​de​ ​un​ ​servidor.

Actualmente Microsoft, debido a la demanda, cuenta con equipo de desarrolladores

open source para su plataforma Azure, esto con el motivo de integrar herramientas
open source como git a los servicios de Azure y de esta manera poder competir con
otras empresas que proveen servicios similares como Amazon Web Services y
Google​ ​cloud​ ​platform.

Además de la integración directa de Node con Azure, Microsoft también ha estado

publicando​ ​una​ ​serie​ ​de​ ​tutoriales​ ​de​ ​Node.
Microsoft también ha anunciado planes para el desarrollo de un proyecto derivado de
[Link], este proyecto difiere en el motor de javascript que utiliza. Este proyecto
utilizará el motor de javascript de su navegador Edge en lugar del motor V8 de
Chrome. Esto demuestra que Microsoft ha visto el enorme potencial en Javascript y
[Link].

Un caso de uso que ha sido desarrollado por el equipo de desarrollo open source de
Microsoft es el de un medidor de insulina en tiempo real para diabéticos. Este
medidor utiliza Azure para su funcionamiento, el cual se encarga de registrar un
historial altamente preciso de la insulina de un paciente y despliega los datos en
gráficas que facilitan la visualización en tiempo real. Para su funcionamiento es
necesario que el paciente esté conectado a un medidor de insulina, el cual se
introduce al cuerpo mediante un implante, sin embargo, esta es una práctica común,
y lo único que se necesita hacer para poder integrar los datos a la plataforma Azure
es extraer estos datos del dispositivo medidor de insulina y enviar la información en
formato​ ​JSON​ ​a​ ​la​ ​plataforma​ ​desarrollada​ ​por​ ​el​ ​equipo​ ​open​ ​source​ ​de​ ​Microsoft.

○ IBM.
IBM de la misma manera que Microsoft cuenta con una plataforma de servicios en la
nube con la cual se pueden desarrollar todo tipo de aplicaciones, desde IoT5 hasta
páginas​ ​web.

Su plataforma, IBM Bluemix soporta varios lenguajes de programación y servicios,

así como la metodología de desarrollo DevOps de forma integrada para crear,
ejecutar,​ ​desplegar​ ​y​ ​gestionar​ ​aplicaciones​ ​en​ ​la​ ​nube.

Esta plataforma soporta [Link] y ofrece herramientas de testeo desarrolladas por el

equipo de desarrollo de Bluemix, herramientas que han recibido excelentes críticas
por​ ​parte​ ​de​ ​los​ ​desarrolladores​ ​que​ ​las​ ​han​ ​utilizado.

IBM también ha visto un potencial enorme en [Link] y ha adquirido una empresa

llamada “StrongLoop”, la cual es responsable del desarrollo de una herramienta de
desarrollo de APIs con [Link] llamada LoopBack. Actualmente, la herramienta
LoopBack continúa siendo de código abierto, pero IBM ahora se encarga de ofrecer
mantenimiento​ ​empresarial​ ​para​ ​compañías​ ​que​ ​utilicen​ ​esta​ ​herramienta.

5
​ ​IoT:​​ ​Internet​ ​of​ ​Things,​ ​en​ ​español​ ​Internet​ ​de​ ​las​ ​cosas.,​ ​se​ ​refiere​ ​a​ ​la​ ​interconexión​ ​de​ ​objetos
cotidianos​ ​a​ ​internet.
Actualmente empresas grandes como Bank of America, GoDaddy y Symantec
utilizan​ ​LoopBack​ ​para​ ​proyectos​ ​de​ ​desarrollo​ ​web.

Otro de los servicios relacionados a LoopBack que IBM ofrece es la fácil integración
con IBM Bluemix, y con la herramienta API Connect, herramienta que permite
visualizar de manera gráfica la composición de las características de nuestro API,
además​ ​tiene​ ​una​ ​interfaz​ ​de​ ​línea​ ​de​ ​comandos​ ​para​ ​la​ ​administración​ ​de​ ​APIs.

IBM también ofrece un SDK6 desarrollado por ellos mismos llamado “IBM​® SDK for
[Link]” el cual provee un runtime de JavaScript independiente que es utilizado en
las soluciones del lado del servidor de JavaScript para las plataformas de IBM. Este
SDK provee alto desempeño, escalabilidad, y un ambiente non-blocking I/O basado
en​ ​eventos​ ​y​ ​desarrollado​ ​en​ ​JavaScript.

Además de esto, IBM ofrece también herramientas externas de monitoreo,

diagnóstico y métricas para aplicaciones [Link]. Algunas de estas herramientas
están incluidas en su plataforma Bluemix, y otras se encuentran como herramientas
por separado. Entre estas herramientas podemos encontrar revisores del
desempeño de garbage collection, reportes de diagnósticos, historiales del
desempeño de nuestra aplicación, examinación de código de fuente, y monitoreo de
disponibilidad​ ​de​ ​la​ ​aplicación.

○ PayPal.
PayPal se está alejando de las tecnologías basadas en Java que utiliza para su
plataforma de pagos en línea, cada vez más utiliza JavaScript con [Link]. PayPal
comenzó utilizando [Link] como una herramienta prototipo, es decir, creación de
aplicaciones web que no eran necesariamente el concepto final y no sabrían si las
utilizarían al ser finalizadas, por lo tanto, sabiendo que la aplicación que prototipar
seria escrita nuevamente desde cero una vez aprobada decidieron utilizar [Link],
pero como resultó ser extremadamente eficiente a comparación de Java decidieron
comenzar​ ​a​ ​utilizar​ ​Node​ ​en​ ​ambientes​ ​de​ ​producción.

La primera instancia en la que PayPal utilizo [Link] en producción no fue una

aplicación chica, fue su página de perfil de cuenta de usuario, cabe mencionar que
esa era una de las páginas que recibe más tráfico de todo su conjunto de
aplicaciones. De manera que no tuvieran resultados tan negativos, el equipo de
desarrollo de PayPal desarrollo simultáneamente una página de perfil de cuenta

6
​ ​SDK:​ ​Software​ ​Development​ ​Kit,​ ​en​ ​español​ ​Kit​ ​de​ ​Desarrollo​ ​de​ ​Software,​ ​es​ ​un​ ​conjunto​ ​de
herramientas​ ​que​ ​le​ ​permiten​ ​al​ ​desarrollador​ ​crear​ ​una​ ​aplicación​ ​informática.
utilizando Java y los resultados probaron la hipótesis de que el equipo de JavaScript
era​ ​capaz​ ​de​ ​desarrollar​ ​un​ ​producto​ ​de​ ​manera​ ​más​ ​rápida​ ​y​ ​eficiente.

PayPal comenzó a utilizar [Link] oficialmente en enero del 2013 y les tomó un par
de​ ​meses​ ​estandarizar​ ​toda​ ​su​ ​infraestructura​ ​para​ ​el​ ​correcto​ ​uso​ ​de​ ​Node.

Los puntos más importantes que llevaron a PayPal a tomar la decisión de seguir
utilizando​ ​Node​ ​fueron​ ​los​ ​siguientes:

❖ Desarrollo​ ​a​ ​casi​ ​el​ ​doble​ ​de​ ​velocidad​ ​con​ ​menos​ ​desarrolladores.
❖ Código para las mismas aplicaciones toman con Node 33% menos líneas de
código.
❖ Desarrollo​ ​con​ ​40%​ ​menos​ ​archivos.
Desde ese momento PayPal aumentó sus esfuerzos de desarrollo con JavaScript y
además ha hecho grandes contribuciones a la comunidad open source de JavaScript
con una herramienta llamada KrakenJS la cual añade una capa extra de seguridad y
escalabilidad​ ​a​ ​los​ ​servidores​ ​[Link].

○ Netflix.
El creciente número de suscriptores de Netflix (cerca de 109.25 millones en el
momento en el que se escribe esta tesis) ha generado un gran número de problemas
de​ ​escalabilidad​ ​para​ ​la​ ​compañía.

Uno de los primeros pasos que Netflix tomo para soportar a su creciente número de
suscriptores fue migrar toda su infraestructura a la nube. Sin embargo, la migración a
la nube no detuvo los problemas de escalabilidad. La nube después de todo es la
computadora de alguien más, y escalar la plataforma para un número grande de
usuarios continúa siendo un problema. Mientras el número de usuarios incrementan,
también incrementa el número de plataformas a las que tenían que enviar
información. En su primera iteración Netflix solo funcionaba en los navegadores,, y la
plataforma entera consiste de un servidor web de Java que se encargaba de un
todas las tareas. El servidor prácticamente hacía todo, desde hacer render de la
Interfaz,​ ​hasta​ ​acceder​ ​a​ ​los​ ​datos.

Netflix utiliza microservicios para proveer un diverso rango de características. Para

cada microservicio hay un equipo de desarrolladores que es “dueño” de ese
microservicio y provee un cliente que hace las peticiones al servidor Java. Este
servidor, sufría de muchos problemas. Para empezar, era muy lento ampliar la
plataforma e innovar. Cada vez que un nuevo show se lanzaba en la plataforma se
debía ampliar la plataforma. Sí uno de los equipos de desarrollo lanzaba una versión
nueva y mejorada de cliente, la plataforma debía de ser ampliada. Cada vez que se
agregaba un microservicio debían de ampliar la plataforma. El incremento en el
número​ ​de​ ​dispositivos​ ​resultaba​ ​en​ ​largos​ ​tiempos​ ​de​ ​respuesta.

En la siguiente iteración de la plataforma, el equipo de desarrollo migró al paradigma

de desarrollo REST API. Esto desbloqueo la posibilidad de soportar mas dispositivos.
El nuevo framework también separaba el render de la interfaz y el acceso a procesos
de datos. Sin embargo, este paradigma no resolvió el 100% de sus problemas. Por
ejemplo, debido a la estructuración de este paradigma, un equipo de microservicios
debía de esperar a que el equipo que del API REST realizará los cambios necesarios
en​ ​el​ ​API​ ​para​ ​soportar​ ​estos​ ​servicios.

Los diferentes equipos de desarrollo necesitaban más flexibilidad para las

plataformas en las que desarrollaban, y el API REST que se había generado como
backend​ ​entorpecia​ ​el​ ​flujo​ ​de​ ​trabajo​ ​debido​ ​a​ ​su​ ​tamaño.

El equipo de desarrolladores de Netflix al ver estos problemas decidió realizar una

solución de Java a la cual llamaron [Link]. [Link] permitia a los equipos de
desarrollo tener su propio API personalizado. Los equipos de desarrollo podrían
cambiar el código referente a sus APIs tanto como quisieran sin afectar a otros
equipos de desarrollo. Los servicios de API podían ser actualizados tanto como
quisieran independientemente. Sin embargo, a pesar de la gran innovación y mejora
en la flexibilidad que representaba esta nueva plataforma, Netflix continuaba
teniendo problemas. Uno de los problemas, era que miles de scripts compartían el
mismo espacio de servidor, por lo tanto, era común que se terminaran los recursos
de los servidores en la nube, y fuera necesario pagar mejoras costosas. Otro
problema que resultó incluso en cortes de servicio era los errores en los scripts que
subían los desarrolladores, sí un script tenía un problema de fuga de memoria podría
afectar​ ​el​ ​sistema​ ​completo.

Otro problema es algo conocido como “ergonomía de desarrollador”. El servidor

[Link] era un software bastante complejo con múltiples partes móviles. Los
scripts no podían ser probados localmente. Para probar un script, el equipo de
desarrolladores tenía que subir el script a un sitio de prueba, correrlo, probarlo, y si
había errores, realizar este proceso nuevamente con los cambios necesarios en el
script. Este proceso era extremadamente ineficiente, lento e inconveniente para los
desarrolladores, y eso es lo que llevó al desarrollo de la siguiente iteración de su
plataforma en la que se tomaban en cuenta la escalabilidad, disponibilidad, y la
productividad​ ​de​ ​los​ ​desarrolladores.

Al desarrollar el framework, se estableció que, en el frente de la escalabilidad y la

disponibilidad, una de las metas era lograr el aislamiento de procesos para evitar los
problemas que tenía [Link]. También requería que los scripts de acceso de
datos y servidores de APIs se mantuvieran separados para reducir costos de la
infraestructura. Los diseñadores también querían reducir el tiempo de carga de las
distintas​ ​secciones.

En el caso de la productividad de los desarrolladores, la mayoría de los

programadores quería utilizar el mismo lenguaje (de preferencia JavaScript) tanto en
el servidor como en el cliente, y no tener que lidiar con dos tecnologías distintas.
También necesitaban la posibilidad de hacer pruebas localmente, agilizar el proceso
de la publicación de proyectos y poder trabajar en ambientes lo más cercanos al de
producción.

El nuevo framework resultante, llamado “New Generation Data Access API” (API de
Acceso de Datos de Nueva Generación) mueve todos los APIs de acceso de datos a
aplicaciones separadas utilizando [Link]. Cada aplicación está aislada en un
contenedor Docker. Los servicios de back-end en esta iteración se encuentran
contenidos en un servidor de Java que el área de desarrollo de Netflix llama “Remote
Service Layer” o RSL (Capa de Servicio Remoto). El RSL integra todos los servicios
de back-end bajo un API consistente. Cuando los desarrolladores quieren lanzar
nuevos​ ​APIs,​ ​suben​ ​JavaScript​ ​al​ ​servidor​ ​en​ ​forma​ ​de​ ​un​ ​contenedor​ ​de​ ​[Link].

○ Uber.
Uber, cuando comenzó a tomar popularidad, doblaba su cantidad de usuarios cada
seis meses. Hoy en dia Uber procesa millones de viajes diariamente, opera en 68
países en 6 continentes y cuenta con conductores en más de 300 ciudades en solo
cinco y medio años de operación. Debido al gran tamaño de las operaciones de uber,
se necesita un sistema que se mantenga en pie hasta en las circunstancias menos
favorables, es por eso que los ingenieros de Uber han escogido [Link] como la
herramienta​ ​de​ ​backend​ ​para​ ​su​ ​plataforma.
El sistema de emparejamiento de usuarios y conductores de Uber genera una
enorme cantidad de notificaciones de los servidores y de solicitudes al mismo. Pero
un viaje no solamente selecciona conductores directamente, informa a conductores
en un radio cercano a la solicitud a través de su proceso de emparejamiento en el
cual los conductores más cercanos son almacenados en una base de datos
geoespacial que continuamente se actualiza por cada conductor activo en la red
mientras se mueven en una ciudad. Las solicitudes van y vienen a distintas
velocidades dependiendo de la potencia en la coneccion a internet de los celulares
de los conductores y los usuarios, pero a cada solicitud se le asigna el mismo nivel
de​ ​importancia.

Afortunadamente,​ ​[Link]​ ​es​ ​especialmente​ ​en​ ​este​ ​tipo​ ​de​ ​situaciones.

“[Link] es particularmente útil para escribir sistemas que almacenan mucha

información de manera interna” (En este caso se puede ver el ejemplo de la base de
datos geoespacial que es almacenada en el dispositivo del usuario) mencionó Kris
Kowal, Ingeniero de software en Uber. “No tienen que externar las preocupaciones
de un sistema distribuido. Y como consecuencia, estos sistemas están más
disponibles, y pueden responder con más rapidez a las solicitudes eliminando la
escritura​ ​y​ ​lectura​ ​y​ ​la​ ​serialización​ ​de​ ​estado​ ​a​ ​la​ ​base​ ​de​ ​datos”.

Una de las fortalezas que Uber ve en [Link] es la rápida iteración, es decir, la

facilidad de publicar nuevas versiones de la plataforma rápidamente. Utilizando un
ambiente de pruebas llamado Read Eval Print Loop REPL (Leer Evaluar Imprimir
Repetir), JavaScript permite a los desarrolladores publicar nuevo código y arreglar
errores​ ​que​ ​el​ ​nuevo​ ​código​ ​pueda​ ​presentar​ ​sin​ ​tener​ ​que​ ​detener​ ​ningún​ ​proceso.

“Una de las cosas que hace a [Link] especial para ser utilizado en producción es
que se puede inspeccionar y cambiar un programa sin tener que reiniciarlo”,
mencionó Ranney, ingeniera en Uber. “De manera que pocos lenguajes ofrecen esa
capacidad. No muchas personas parecen saber que esa capacidad existe, pero en
efecto se puede inspeccionar e incluso cambiar un programa mientras está
ejecutándose​ ​sin​ ​tener​ ​que​ ​reiniciarlo”.

Esto permite la resolución de problemas a velocidad superior a la de otros lenguajes

de programación y genera una cultura de creatividad y productividad en el creciente
equipo​ ​de​ ​ingenieros​ ​de​ ​Uber.

“Todos están muy motivados a resolver problemas y existe mucho entusiasmo y

energía en los equipos de desarrollo” dijo Ranney “El equipo es extremadamente
productivo”.
Otra fortaleza que el equipo de desarrollo de Uber encuentra en [Link] es la
comunidad open source alrededor de la plataforma, esto genera un ambiente de
resolución de problemas social, de manera que muchos desarrolladores de distintas
partes del mundo y compañías se ayudan mutuamente para encontrar soluciones
para esos problemas y comparten sus soluciones públicamente con la comunidad
open​ ​source.

Esto es especialmente útil cuando tienes problemas de fuga de memoria, ya que

según los desarrolladores de Uber si planeas publicar un proyecto en [Link] que
eventualmente escale a una gran cantidad de usuarios, lo más probable es que
tengas​ ​que​ ​lidiar​ ​con​ ​problemas​ ​de​ ​fuga​ ​de​ ​memoria.

La fuga de memoria es un problema conocido, y la comunidad open source ha

creado una gran variedad de herramientas para diagnosticar y solucionar estos
problemas. Joyent, el primer patrocinador de [Link] tiene herramientas para
resolver estos problemas. Existen también herramientas parecidas que no son open
source y están hechas para empresas que requieran herramientas de grado
enterprise.

“La comunidad open source está produciendo toneladas y toneladas de software”

mencionó Ranney, “Honestamente, la parte más difícil de desarrollar con [Link] es
no tener que escribir tus propias herramientas, solamente debes de buscar y
encontrar​ ​la​ ​herramienta​ ​que​ ​más​ ​sea​ ​útil​ ​para​ ​su​ ​implementación”.

“Al desarrollar en [Link], debido a su naturaleza open source, obtenemos los

beneficios de tener muchas personas mejorando el software sin tener nosotros que
hacer nada. Podemos, prácticamente relajarnos en ese ámbito y dejar que mejore
por​ ​sí​ ​solo,​ ​lo​ ​cual​ ​está​ ​bastante​ ​bien.”

“También es interesante que el punto de compromiso al que ha llegado la comunidad

, la mayoría de nuestros problemas son resueltos por la comunidad debido a lo
involucrados​ ​que​ ​están​ ​en​ ​el​ ​desarrollo​ ​de​ ​estas​ ​herramientas.”

“No creo que nos damos cuenta por el momento de el potencial completo que tiene
JavaScript, con su presencia en el lado del cliente y en el lado del servidor y las
múltiples capas que se encuentran en medio” dijo Kowal. “El potencial de tener
codigo modular, reusable que corre literalmente en cualquier lugar aun es un
potencial​ ​que​ ​debemos​ ​comenzar​ ​a​ ​aprovechar”.
 ● Walmart.
En años pasados Waltmart se ha decidido a generar un equipo de desarrollo interno
que realice los trabajos de software que previamente delgaba a empresas de
desarrollo de software empresarial cómo IBM. Esto con el motivo de bajar los costos
de desarrollo de software para la compañía. Eventualmente con las ventajas que
ofrece tener un equipo de desarrolladores a la disposición de una compañía
multinacional los ejecutivos de Walmart decidieron desarrollar un sistema de
comercio​ ​electrónico​ ​para​ ​competir​ ​con​ ​compañías​ ​como​ ​Amazon.

[Link] actualmente ofrece más de 23 millones de artículos a la venta, y se

expande rápidamente, a principios del año 2017 Walmart anunció que estaría
invitando a marcas y vendedores independientes a vender productos a través de su
página​ ​web.

Walmart actualmente recibe cerca de 20,000 visitas por segundo en su sitio web y
aplicaciones móviles durante temporadas festivas, de manera que su sistema de
backend necesita ser rápido, confiable, fácil de usar, y sobre todo escalable para
lograr la meta de competir contra los gigantes del comercio electrónico Amazon,
eBay​ ​y​ ​Alibaba.

Las fortalezas principales de [Link] que lo hacen la herramienta adecuada para

Walmart​ ​y​ ​otros​ ​sitios​ ​de​ ​comercio​ ​electrónico​ ​incluyen:

❖ La posibilidad de manejar muchas peticiones concurrentes en su

sistema utilizando el paradigma de desarrollo non-blocking I/O con
[Link] y aprovechando el único thread y event loop que hacen tan
eficiente​ ​a​ ​está​ ​herramienta.
❖ La fácil implementación de librerías de desarrollo frontend ayudan a
desarrollar mejores interfaces en un periodo corto de tiempo y además,
la implementación de la librería [Link] ayuda a Walmart a
mantenerse en un puesto alto de los resultados de Google y otros
buscadores.
❖ El uso de desarrolladores tanto en frontend cómo en backend, debido a
que​ ​el​ ​uso​ ​de​ ​JavaScript​ ​se​ ​da​ ​en​ ​ambas​ ​áreas.

En resumen, Walmart ha sido capaz de llevar características muy sofisticadas a

usuarios móviles y de computadores de escritorio debido a la velocidad con la que
[Link]​ ​puede​ ​enviar​ ​los​ ​datos​ ​de​ ​los​ ​contenidos​ ​de​ ​su​ ​pagina.
“Hemos estado fascinados por mucho tiempo en el uso de JavaScript tanto para
backend cómo para frontend” dijo Ben Galdraith vicepresidente de desarrollo móvil
en​ ​Walmart.

Otra ventaja que han encontrado en el uso de está tecnología es la facilidad con la
que pueden reclutar nuevo talento, debido a que los programadores más curiosos
están​ ​siempre​ ​dispuestos​ ​a​ ​trabajar​ ​con​ ​las​ ​nuevas​ ​tecnologías.
 ● Estado​ ​del​ ​arte.
La fundación [Link] anualmente realiza una investigación a nivel mundial para
entender mejor para que se usa [Link] hoy en dia, y para identificar las posibles
mejoras​ ​y​ ​finalmente​ ​publica​ ​los​ ​resultados.

Esta investigación fue conducida en línea del 30 de Noviembre al 16 de Enero de

2017, a través de una encuesta sta7, en la cual participaron 1405 desarrolladores en
total. Las respuestas fueron analizadas por una agencia de consultoría de
investigación​ ​independiente.

A continuación se muestran imágenes con gráficas y resúmenes de los resultados

que​ ​presentaron​ ​estos​ ​estudios.

En esta imagen se puede apreciar la gran cantidad de compañías que utilizan

[Link] y el gran rango de industrias que cubre esta plataforma, desde empresas
que manufacturan hardware como GoPro, hasta empresas de noticias y empresas
más​ ​tradicionales​ ​de​ ​informática​ ​como​ ​Trello,​ ​Yahoo​ ​y​ ​Cisco.

7
​ ​Resumen​ ​de​ ​la​ ​investigación:​ ​[Link]
En esta Imagen se pueden apreciar las distintas áreas en las que las compañías
implementan [Link] y como podemos observar y era de esperarse, la mayoría de
las compañías lo utilizan para sus sistemas back-end, en este caso esta gráfica
también​ ​incluye​ ​a​ ​los​ ​APIs​ ​como​ ​parte​ ​de​ ​desarrollo​ ​backend.

Como segundo lugar en usabilidad con el 61% de las empresas utilizando [Link] de
esta manera podemos ver que se utiliza [Link] para desarrollo FullStack, es decir,
tanto para el desarrollo del back-end, como el desarrollo del front-end, esto es una
práctica común para empresas que se concentran en desarrollar sistemas web
principalmente, y es aquí donde entra la versatilidad y gran ventaja de la
herramienta, debido a que puede ser usada en ambas áreas, por lo tanto, es más
fácil para un desarrollador o grupo de desarrolladores poder desarrollar para ambas
áreas, practica que se le conoce como FullStack y que está creciendo en popularidad
debido a que implica para las empresas un menor gasto en términos de recursos
humanos.

En tercer lugar con 51% de usabilidad tenemos front-end como aplicación de [Link]
en las empresas encuestados, dato que inicialmente puede resultar un poco raro,
pero podemos tomar en cuenta que [Link] puede ser utilizado para el consumo de
APIs,​ ​de​ ​manera​ ​que​ ​pueda​ ​utilizarse​ ​en​ ​el​ ​front-end.

Un dato interesante es que podemos encontrar a IoT con un 12% de utilización por
las empresas encuestadas, tecnología que actualmente se encuentra dominada por
lenguajes de programación de más bajo nivel, pero [Link] demuestra en este caso
su​ ​versatilidad​ ​escabulléndose​ ​en​ ​este​ ​campo.

En la siguiente imagen podemos apreciar el tipo de tecnologías que se utilizan en

conjunto​ ​con​ ​[Link]​ ​comúnmente.

En primer lugar tenemos las bases de datos con 95% de los encuestados utilizando
está tecnología en conjunto con [Link], lo cual no es sorprendente, ya que las
bases de datos son el pilar de las aplicaciones web. Un detalle importante con
[Link]​ ​es​ ​que

Tenemos en segundo lugar las librerías y frameworks de front-end que son usadas
en conjunto con [Link] con un 85% de uso por los encuestados, en este caso
podemos ver una correlación con la gráfica anterior en la cual se muestra que un
gran​ ​número​ ​de​ ​encuestados​ ​utiliza​ ​[Link]​ ​para​ ​desarrollo​ ​FullStack​ ​y​ ​front-end.

En tercer lugar tenemos a frameworks que extienden a [Link], y en los siguientes

lugares podemos ver que se componen principalmente de herramientas de
operaciones de desarrollo como load balancing, containers, continuous integration
(integración​ ​continua)​ ​y​ ​sistemas​ ​de​ ​mensajería.

En está imagen podemos apreciar que se contabiliza el tipo de desarrollo que

realizan los encuestados, y podemos observar como [Link] es también utilizado en
el​ ​ambiente​ ​empresarial.

Como tipo de desarrollo principal tenemos las aplicaciones web, lo cual no sobresale
mucho, ya que el desarrollo de aplicaciones web es el principal objetivo por el cual
fue desarrollado [Link]. En este caso el desarrollo de aplicaciones web cuenta con
un​ ​84%​ ​de​ ​uso​ ​por​ ​los​ ​encuestados.

En segundo lugar tenemos al desarrollo empresarial, y con esto podemos ver que las
empresas cada vez ven más las ventajas del uso de [Link] en sus aplicaciones
web. Esto le da seriedad a [Link] y hace que empresas que utilizan exclusivamente
software​ ​empresarial​ ​lo​ ​consideren​ ​como​ ​una​ ​opción​ ​de​ ​desarrollo.

A continuación tenemos BigData y analytics. Estos tipos de desarrollo han crecido

recientemente en popularidad debido a las ventajas de negocios que proveen el
análisis de datos a gran escala, ya que al tener datos se pueden tomar mejores
decisiones​ ​de​ ​manera​ ​objetiva.
Y por último tenemos los sistemas embebidos, los cuales presentan una correlación
con la segunda imagen mostrada en la cual toma un 12% de uso [Link] en
desarrollo​ ​de​ ​Internet​ ​of​ ​Things​ ​o​ ​IoT.

En estas gráfica podemos observar 2 tipos de datos diferentes, primero, tenemos la

versión de [Link] utilizada por los encuestados, y podemos darnos cuenta que la
mayoría de los desarrolladores encuestados utilizan las versiones de [Link] con
Long​ ​Term​ ​Support​ ​LTS​ ​(soporte​ ​a​ ​largo​ ​plazo).

Las versiones cubiertas por LTS son mantenidas activamente por un periodo de 18
meses contando desde el día en el que entra a su cobertura LTS. Después de los 18
meses de soporte activo, esta versión transiciona a un modo de “mantenimiento” por
12​ ​meses​ ​adicionales.

La fecha exacta en la que una versión es movida a LTS o movida entre modos
distintos de LTS, o nombrada obsoleta será siempre el primer día de un mes. Sí la
versión será movida se notificará de está acción a la comunidad de desarrolladores
[Link]​ ​con​ ​14​ ​dias​ ​de​ ​anticipacion.

Debido a estas regulaciones nunca existen más de dos versiones LTS activas al
mismo​ ​tiempo​ ​por​ ​más​ ​de​ ​seis​ ​meses.
Gracias a la naturaleza de alto soporte a estas versiones es la razón por la que los
desarrolladores​ ​prefieren​ ​desarrollar​ ​aplicaciones​ ​empresariales​ ​con​ ​versiones​ ​LTS.

El segundo tipo de dato que podemos apreciar en está imagen son las gráficas que
nos permiten visualizar los sistemas operativos utilizados por los desarrolladores
para hacer aplicaciones [Link] y una comparación del uso de estos sistemas
operativos en producción, es decir, el sistema operativo de los servidores en los que
corren​ ​estas​ ​aplicaciones.

En primer lugar de uso de sistema operativo para desarrollo es MacOs con el 46%
de los desarrolladores, lo cual parece ser una tendencia reciente para el desarrollo
web, debido a la comodidad que ofrece el sistema operativo para tareas cotidianas,
pero a la vez teniendo un fuerte enfoque en desarrollo con una gran variedad de
herramientas para la terminal, la cual puede resultar familiar para desarrolladores
que​ ​han​ ​utilizado​ ​sistemas​ ​linux​ ​o​ ​unix​ ​en​ ​el​ ​pasado.

Podemos ver que en contraste MacOs es utilizado muy poco con un 3% para el
ambiente de producción, ya que a pesar de que Apple, la compañía detrás de este
sistema operativo sí cuenta con soluciones para servidor, no tiene un pasado tan
amplio​ ​en​ ​el​ ​servidor​ ​como​ ​Linux​ ​o​ ​inclusive​ ​Windows.

En segundo lugar para ambientes de desarrollo de aplicaciones [Link] se

encuentra Ubuntu, ambiente en el cual el uso de [Link] resulta fácil debido a la
terminal de Linux la cual está perfectamente adecuada para el uso de herramientas
relacionadas​ ​a​ ​[Link]​ ​como​ ​el​ ​manejador​ ​de​ ​paquetes​ ​npm.

Y en contraste podemos ver que el ambiente de producción ve un alto uso de

Ubuntu, el más alto de todos los sistemas operativos, esto demuestra la fuerte
presencia​ ​de​ ​Linux​ ​en​ ​el​ ​lado​ ​del​ ​servidor.

Después de Ubuntu podemos ver Windows con un 18% de uso por los
desarrolladores encuestados. Un alto porcentaje considerando las ventajas que
presentan los sistemas operativos Unix o similares en contraste a Windows. Esto
puede deberse al alto porcentaje de usuarios en general que tiene Windows. Para
muchos desarrolladores que han utilizado Windows toda su vida, incluso desde antes
de convertirse en desarrolladores cambiar de sistema operativo a algo tan diferente
como MacOs o Linux puede parecer un cambio demasiado drástico con una curva de
aprendizaje​ ​muy​ ​alta.
Windows​ ​en​ ​ambiente​ ​de​ ​producción​ ​es​ ​poco​ ​usado​ ​con​ ​solo​ ​un​ ​8%​ ​de​ ​uso.

Despues de Windows podemos ver otros sistemas operativos Linux tanto para el
ambiente de desarrollo como para el ambiente de producción, y se puede ver que la
presencia de sistemas operativos empresariales como fedora tienen un porcentaje
bajo​ ​con​ ​14%​ ​de​ ​uso​ ​en​ ​produccion​ ​y​ ​4%​ ​en​ ​ambiente​ ​de​ ​desarrollo.

En está imagen podemos ver que los desarrolladores encuestados han notado
mejoras al cambiar de herramienta de desarrollo y comenzando a utilizar [Link] han
notado​ ​las​ ​siguientes​ ​mejoras:

● 68%​ ​en​ ​incremento​ ​de​ ​la​ ​productividad​ ​del​ ​desarrollo.

● 65%​ ​mayor​ ​satisfacción​ ​de​ ​los​ ​desarrolladores.
● 58%​ ​en​ ​reducción​ ​de​ ​costos​ ​de​ ​desarrollo.
● 50%​ ​de​ ​incremento​ ​en​ ​el​ ​desempeño​ ​de​ ​las​ ​aplicaciones.

En resumen podemos ver que hay un incremento en la productividad y un

decremento en los costos de desarrollo y un incremento en el desempeño de las
aplicaciones​ ​lo​ ​cual​ ​implica​ ​un​ ​decremento​ ​en​ ​el​ ​costo​ ​de​ ​operaciones.
Como podemos ver las ventajas de [Link] son visibles en las mejoras vistas por los
desarrolladores​ ​encuestados.

[Link] ha incrementado su popularidad globalmente a través de los años, a

diferencia de otras herramientas cuya popularidad es mucho más grande en unos
países que en otros, tal es el caso de Java y su alta popularidad en la India pero no
tanto​ ​en​ ​otros​ ​países.

En está gráfica podemos ver el aumento en popularidad mundialmente de [Link] en

comparación​ ​a​ ​su​ ​popularidad​ ​en​ ​el​ ​año​ ​pasado.

Con el mayor porcentaje de adopción de la herramienta [Link] en este año

podemos ver a latino america, region en la cual su popularidad creció un 86%. Es
además,​ ​la​ ​región​ ​donde​ ​más​ ​se​ ​espera​ ​crecimiento​ ​en​ ​los​ ​siguientes​ ​años.

Justo después de latino américa se encuentra china con un crecimiento en la

adopción de está herramienta de un 79%, a pesar de que esta región queda en
segundo lugar, debido a la cantidad de población que tiene, representa un aumento
muy​ ​significativo​ ​en​ ​cantidad​ ​de​ ​desarrolladores.

Colectivamente los usuarios de [Link] se extienden a 85 países y hablan más de

45​ ​idiomas.

En Está imagen podemos apreciar el alcance global de [Link], el cual se extiende

alrededor del mundo. Se puede observar los idiomas hablados por los
desarrolladores​ ​encuestados​ ​por​ ​porcentaje.

Como es de esperarse, la mayor parte de los desarrolladores que utilizan [Link]

hablan inglés y se encuentran en la región de Estados Unidos y Canadá
conformando el 47% de los usuarios de [Link], esto debido a la alta concentración
de desarrolladores en estos países., ya que, como es sabido, Sillicon Valley, la
región de desarrollo de tecnología más grande del mundo se encuentra en el estado
de​ ​California​ ​en​ ​Estados​ ​Unidos.
Después siguen el mandarín, español, alemán, y francés con 6% cada uno, lo cual
resulta ser un dato muy interesante, porque eso significa que los hispanohablantes
representan una cantidad igual de desarrolladores que los provenientes de la región
de​ ​China​ ​y​ ​de​ ​otros​ ​países​ ​de​ ​primer​ ​mundo​ ​como​ ​alemania​ ​y​ ​francia.

Uno de los principales factores de éxito para una herramienta de desarrollo en la

facilidad con la que se puede aprender, ya que resulta contraproducente invertir
mucho tiempo en una herramienta independientemente de las ventajas que pueda
proveer​ ​en​ ​un​ ​futuro.

En está gráfica se muestran las formas de aprendizaje informal más utilizadas por los
desarrolladores de [Link], el aprendizaje informal es aquella que existe fuera de un
currículum estructurado,es decir, el aprendizaje que se da de una manera no
convencional y por lo general no se realiza en un ambiente oficial, estructurado y
formal, en el caso de los desarrolladores, es la manera más común en la que se
adquiere conocimiento, por lo general un desarrollador se aventura a investigar en
distintas fuentes de información e intenta absorber todo el conocimiento posible. Por
lo tanto en el caso de una herramienta de desarrollo es vital que existan múltiples
fuentes claras y concisas de información, de manera que sea fácil para los
desarrolladores​ ​comprender​ ​los​ ​conceptos​ ​que​ ​pueda​ ​presentar​ ​está​ ​herramienta.

Podemos ver en está gráfica que la mayoría de los desarrolladores aprendió a utilizar
[Link] viendo cursos en línea sin ningún instructor formal y muchos otros
aprendieron de una fuente de información muy popular entre desarrolladores [Link]
llamada​ ​NodejsSchool.

Como último pedazo de información sobre el estado del arte quiero presentar en
nivel de interés de los desarrolladores en contribuir con proyectos [Link] open
source.

Podemos ver que el 26% de los desarrolladores encuestados dijeron que estarían
interesados en apoyar el desarrollo de proyectos open source de [Link], y a pesar
de que no todos los desarrolladores que contestaron que están interesados
verdaderamente terminan apoyando el desarrollo, el porcentaje de interés resulta ser
bastante​ ​alto​ ​comparado​ ​con​ ​otros​ ​proyectos.

Y donde se ve mucho más interés es en dar tutorías a nuevos desarrolladores o a

desarrolladores que nunca han utilizado [Link], con un 40% de interés por parte de
los encuestados se puede ver que la satisfacción con la herramienta es tal que
muchos desarrolladores estarían dispuestos a dar su tiempo para ayudar a nuevos
desarrolladores​ ​a​ ​empezar​ ​a​ ​usar​ ​[Link].

● Sumario.
Como podemos observar, [Link] ha sido ampliamente adoptado por empresas de
alto perfil, empresas medianas, y desarrolladores independientes. En américa latina
ha adquirido mucha fama en 2017 con el mayor porcentaje de aumento en adopcion
por​ ​desarrolladores​ ​de​ ​la​ ​región.

En China el porcentaje de adopción es menor, pero debido a la cantidad de

población la cantidad de desarrolladores que han comenzado a utilizar [Link] en el
2017​ ​es​ ​mucho​ ​mayor​ ​a​ ​la​ ​de​ ​las​ ​demás​ ​regiones.

El crecimiento del proyecto open source [Link] y su adopción masiva lo convierte

en una de las herramientas más utilizadas en el mundo para el desarrollo web y esto
puede verse de manera objetiva con las estadísticas y casos de uso presentados
anteriormente.
CAPÍTULO​ ​III.​ ​METODOLOGÍA

Diseño.
Para la realización de está tesina se utilizó el método lógico inductivo, debido a que
se toman en cuenta casos particulares los cuales en está tesina se presentan como
los casos de uso vistos en el capítulo anterior, y por lo tanto, de esos casos
formulamos la hipótesis de que la adopción masiva de [Link] que se ha dado en los
últimos años es un fantástico indicativo de un futuro con más crecimiento para está
herramienta. Este método se utiliza ya que la información que se tiene al respecto es
altamente limitada ya que es imposible conseguir numeros exactos del uso de está
herramienta, esto porque muchas empresas deciden mantener como información
confidencial las tecnologías que utilizan, así como es imposible contactar a cada
persona que haya descargado está herramienta para preguntar sí aún continúan
utilizandola. De manera que observamos casos de uso y utilizamos la información
limitada​ ​que​ ​tenemos​ ​disponible​ ​para​ ​formar​ ​nuestra​ ​hipótesis.

● Partes del método lógico inductivo utilizadas en está

investigación.
Debido a que no todos los elementos del objeto de investigación pueden ser
numerados y estudiados en su totalidad, se considera una investigación por
inducción​ ​incompleta.

Se tomó información de investigaciones anteriores realizadas por distintos medios e

instituciones los cuales solo pudieron adquirir una muestra representativa, de la cual
pudieron​ ​hacer​ ​generalizaciones​ ​más​ ​adelante.

Especificando un poco más, este es un método de inducción incompleta por

conclusión probable, debido a que la muestra de casos de uso de [Link] en
ambientes de producción es muy grande, y aún si se tuviera la posibilidad de
contactar a todos los desarrolladores y empresas que utilizan está herramienta en
producción, no todos los contactados estarían dispuestos a proveer información
debido a que quizá esa información sea confidencial, o afecte la seguridad o proceso
de​ ​negocios​ ​de​ ​su​ ​empresa.

De manera que tome en cuenta solamente los casos de uso proveídos por empresas
a la fundación [Link] los cuales, a pesar de ser pocos, provienen de empresas
grandes, lo cual demuestra las ventajas de está herramienta, ya que las empresas
grandes se topan con problemas que pocas empresas chicas o medianas tienen que
lidiar.

Estas empresas presentaron comentarios muy positivos acerca de [Link], lo cual

indica que los equipos de desarrollo se encuentran bastante felices con las mejoras
que ha traído. Esto lo menciono debido a que conociendo el ambiente de desarrollo
que se da en una empresa mediana se que es muy difícil para un desarrollador o
grupo de desarrolladores tomarse el tiempo de responder preguntas por parte de una
organización o escribir acerca de las herramientas que utilizan, esto resulta ser una
actividad que toma mucho tiempo, esfuerzo y no genera dinero para la empresa. El
simple hecho de que tantos desarrolladores de empresas tan grandes indica su
agradecimiento​ ​con​ ​está​ ​herramienta.

Desarrollo.
En el desarrollo de está investigación se presentó una situación muy particular, en la
cual se me dificulto la obtención de información de medios tradicionales, es decir, a
través de libros, artículos de investigación y revistas relacionadas con el campo de la
informática.

Debido a lo reciente que es está herramienta, la cual en términos de informática y en

un contexto histórico comparada con otras herramientas puede decirse que aún está
dando sus primeros pasos, fue difícil encontrar información detallada acerca de su
historia, pero gracias al entusiasmo de la comunidad pude recabar información de
distintas páginas web en las cuales se describen las etapas de desarrollo inicial de
está​ ​herramienta.

La pagina oficial de [Link] ​[Link] fue un recurso especialmente útil

debido a su amplio catálogo de casos de uso los cuales se presentan en formato
PDF​ ​y​ ​están​ ​muy​ ​bien​ ​redactados.
Durante mi investigación utilice muchos artículos encontrados en distintas páginas
web, los cuales resultaron de gran ayuda, también utiliza varios libros sobre el tema
de los cuales no pude obtener mucha información objetiva sobre las ventajas de uso
de la herramienta debido a que en su totalidad eran libros didácticos del tema, a
pesar de esto sí encontré un poco de información útil la cual utilice, y la cual
eventualmente​ ​me​ ​llevó​ ​a​ ​fuentes​ ​externas​ ​que​ ​explican​ ​más​ ​a​ ​fondo​ ​el​ ​tema.

Durante la investigación de los casos de uso no solamente utilice la página oficial de

[Link], también utilice un artículo al cual hago referencia en la bibliografía, el cual
explica un poco sobre los casos de uso mencionados, y provee videos de una
conferencia oficial de [Link] del año 2016 en la cual exponentes de distintas
empresas explicaban elaboradamente como ellos o sus equipos de desarrollo
utilizaban está herramienta y como mejoro su productividad como desarrolladores.
También mencionan una gran variedad de ventajas que ven en la herramienta, y
hablan un poco del futuro de la misma y el rol que juegan las empresas grandes
como Microsoft Uber y Netflix en su desarrollo. Algunas empresas como Uber y
Microsoft también hicieron mención de herramientas que ellos han desarrollado con
[Link] y que están disponibles para todos los desarrolladores con licencia open
source.

A pesar de que no fue incluida en este trabajo, la información encontrada en forma

de comentarios de desarrolladores en distintos foros fue de crucial importancia para
validar la información dada por las empresas grandes, ya que no sería una muy
buena práctica solo tomar en cuenta los casos de uso de equipos grandes de
desarrollo, es también necesario saber cómo se comporta está herramienta con
equipos​ ​chicos​ ​y​ ​medianos​ ​además​ ​de​ ​desarrolladores​ ​individuales.
CAPÍTULO​ ​IV.​ ​RESULTADOS

Introducción.
Escoger un lenguaje o herramienta en la cual desarrollar aplicaciones web puede ser
una tarea igual de difícil que realizar la aplicación en sí. A continuación se formulan
los resultados de está investigación la cual tiene como objetivo principal presentar las
ventajas principales de [Link] como herramienta de desarrollo web sobre otras
herramientas más establecidas y con más tiempo y popularidad entre
desarrolladores.

Comprender el modelo de Input y el Output (I/O) de una aplicación puede significar

una gran diferencia entre una aplicación que maneja bien la carga que se le asigna y
una aplicación que deja de funcionar correctamente cuando se encuentra en
ambientes de producción y se le da uso intensivo. Quizá mientras una aplicación es
chica y no tiene que tratar con mucha carga no representa un problema para los
desarrolladores, pero mientras el tráfico de la aplicación incremente, trabajar con el
modelo​ ​de​ ​Input​ ​y​ ​Output​ ​erróneo​ ​puede​ ​resultar​ ​en​ ​problemas​ ​graves.

Y como la mayoría de las situaciones, una situación en la que existen múltiples

formas posibles de afrontar un problema no solo se trata de decidir cuál solución es
la mejor, sino de analizar las ventajas y desventajas exactas de cada solución, es
decir, puede ser que una herramienta provea mejor desempeño pero su codigo sea
mucho menos legible y este mucho menos documentado y por lo tanto su tiempo de
desarrollo​ ​será​ ​mucho​ ​más​ ​alto.

En está investigación se comparan las herramientas [Link], Java, Go y PHP, se

discutirá cómo los diferentes lenguajes y herramientas modelan su Input y su Output,
así​ ​como​ ​las​ ​ventajas​ ​y​ ​desventajas​ ​de​ ​cada​ ​modelo.
Análisis​ ​de​ ​datos.
Para entender los factores involucrados en los modelos de Input y Output, primero
debemos de revisar los conceptos a nivel del sistema operativo. A pesar de que es
improbable que tengamos que lidiar con muchos de estos conceptos directamente se
utilizan indirectamente cuando utilizamos el entorno de ejecución de nuestra
aplicaciones todo el tiempo y espor eso que debemos de al menos comprender los
conceptos​ ​básicos​ ​detrás​ ​de​ ​estos​ ​modelos.

● Llamadas​ ​al​ ​sistema.

Primeramente tenemos las llamadas al sistema, las cuales pueden ser descritas de
la​ ​siguiente​ ​manera:

❖ El programa en ejecución debe pedirle al kernel del sistema operativo

que​ ​realice​ ​una​ ​operación​ ​de​ ​I/O​ ​para​ ​el.
❖ Una “syscall” es la manera en la que tu programa le pide al kernel que
haga algo. Las maneras en las que se realiza está acción específica
pueden variar mucho de un sistema operativo a otro, pero el concepto
es el mismo. Va a haber una instrucción específica que transfiere
control de tu programa hacia el kernel (algo así como una llamada de
función pero con datos específicos para lidiar con este tipo de
situaciones). En general, las syscalls son de tipo “blocking”, lo cual
quiere decir que el programa espera a que el kernel regrese la
respuesta​ ​para​ ​entonces​ ​volver​ ​a​ ​la​ ​ejecución​ ​del​ ​código.
❖ El kernel realiza la operación I/O en el dispositivo físico para el cual se
este especificando la acción en el programa (disco, tarjeta de red, etc),
y responde al syscall. En el mundo real, el kernel quizá deba de hacer
un número de acciones para poder realizar la solicitud del programa
incluyendo esperar a que el dispositivo esté listo, actualizar su estado
 interno, etc, pero como desarrollador de una aplicación no te debe de
importar​ ​eso,​ ​ya​ ​que​ ​es​ ​trabajo​ ​del​ ​kernel.

A continuación se puede apreciar una representación gráfica de un syscall de

manera que se pueda entender con más facilidad cómo se ejecutan las llamadas al
sistema.

● Llamadas​ ​blocking​ ​vs.​ ​[Link].

Como se ha mencionado anteriormente, las llamadas al sistema se clasifican como
blocking, y eso es verdad en un sentido general. Sin embargo, algunas llamadas son
categorizadas como “non-blocking”, lo cual quiere decir que el kernel toma tu
solicitud, la pone en cola o en un buffer, y después es inmediatamente regresada sin
esperar a que ocurra I/O. De manera que es blocking pero solo por una breve
cantidad​ ​de​ ​tiempo,​ ​el​ ​suficiente​ ​para​ ​sacar​ ​de​ ​la​ ​cola​ ​a​ ​tu​ ​solicitud.
Algunos ejemplos de llamadas al sistema en linux quizá puedan ser útiles para dejar
más en claro lo mencionado anteriormente. “read()” es una llamada de tipo blocking,
le pasas un parámetro especificando que archivo y un buffer especificando a donde
debe de enviar los datos que lee, y la llamada regresa cuando los datos se
encuentran​ ​completamente​ ​almacenados​ ​ahí.

Es importante entender que el orden de magnitud en la diferencia de tiempos de las

llamadas. Sí el núcleo de un CPU está corriendo a 3GHz, sin adentrarnos mucho a
optimizaciones de CPU, se encuentra realizando 3 billones de ciclos por segundo o 3
ciclos por nanosegundo. Una llamada al sistema non-blocking puede puede llevar
decenas de ciclos para completarse, o relativamente unos cuantos nanosegundos.
Una llamada blocking que recibe información a través de una red puede tomar
mucho más tiempo, aproximadamente 200 milisegundos (⅕ de un segundo). Y
digamos, por ejemplo, que la llamada [Link] en esa misma situación toma
cerca de 20 nanosegundos, y la llamada blocking tomo 200,000,000 nanosegundos.
El​ ​proceso​ ​blocking​ ​tomo​ ​10​ ​millones​ ​de​ ​veces​ ​más​ ​que​ ​el​ ​proceso​ ​non-blocking.
El kernel provee maneras de hacer tanto llamadas blocking I/O (“lee los datos de
está coneccion de red y dame los datos”) y llamadas non-blocking I/O (“dime cuando
cualquiera​ ​de​ ​estas​ ​conecciones​ ​de​ ​red​ ​tengan​ ​nuevos​ ​datos”).

● Organización.
El tercer concepto que es muy importante es que sucede cuando un programa tiene
muchos​ ​threads​ ​o​ ​procesos​ ​que​ ​comienzan​ ​a​ ​bloquearse.

Para el caso de está investigación no hay una gran diferencia entre un thread y un
proceso. En la vida real la diferencia más notable relacionada al rendimiento de un
programa es que debido a que los threads comparten la misma memoria y los
procesos tienen su propia memoria, hacer procesos separados tiende a consumir
más memoria. Pero cuando estamos hablando de organización, a lo que nos
estamos refiriendo es a una lista de cosas (ya sea procesos o threads) que cada una
tienen un pedazo de tiempo de ejecución el los núcleos disponibles del CPU. Sí se
tienen 300 threads corriendo en 8 núcleos se debe de dividir el tiempo de manera
que cada uno obtenga su parte, con cada núcleo corriendo por una corta cantidad de
tiempo y después moviéndose al siguiente thread. Esto se hace a través de “cambio
de​ ​contextos”,​ ​de​ ​manera​ ​que​ ​el​ ​CPU​ ​ ​cambia​ ​de​ ​un​ ​thread/proceso​ ​al​ ​siguiente.

Estos cambios de contexto tienen un costo asociado, toman una cantidad de tiempo.
En algunos casos son bastante rápidos y toman solamente 100 nanosegundos
aproximadamente, pero es muy común que lleguen a tardar 1000 nanosegundos o
aún más dependiendo de los detalles de la implementación, la velocidad del
procesador​ ​y​ ​su​ ​arquitectura,​ ​la​ ​caché​ ​del​ ​CPU,​ ​etc.

Mientras mayor sea la cantidad de threads o procesos, hay una mayor cantidad de
cambios de contexto. Cuando hablamos de miles de threads y cientos o miles de
nanosegundos​ ​asignados​ ​a​ ​cada​ ​uno​ ​el​ ​procesamiento​ ​puede​ ​resultar​ ​un​ ​tanto​ ​lento.

Sin embargo, las llamadas non-blocking en esencia le dicen al kernel “solamente

llámame cuando tengas nuevos datos o evento en una de estas conecciones.” Estas
llamadas non-blocking están diseñadas para manejar eficientemente cargas pesadas
de​ ​I/Oy​ ​reducir​ ​el​ ​cambio​ ​de​ ​contexto.

Antes de ver ejemplos de cómo diferentes lenguajes de programación hacen estas

llamadas es importante mencionar que a pesar de que los ejemplos mostrados en
está investigación con triviales y parciales, el acceso a la base de datos, sistemas
externos de caché, y cualquier cosa que requiere I/O necesitara realizar algún tipo de
llamada I/O lo cual tendrá efectos esencialmente iguales a los de los ejemplos
mostrados. Además, para los escenarios en los que el I/O es descrito como
“blocking” (PHP, Java), las peticiones HTTP y lecturas de respuestas y escrituras de
las​ ​mismas​ ​son​ ​en​ ​sí​ ​llamadas​ ​de​ ​tipo​ ​blocking.

Existen muchos factores que existen al escoger un lenguaje de programación o

herramienta al comenzar un proyecto. A continuación se muestra una comparación
entre lenguajes y herramientas populares, el primer lenguaje en ser analizado será
PHP.

● PHP.
El modelo que utiliza PHP es bastante simple. Existen algunas variaciones, pero la
mayoría​ ​de​ ​los​ ​servidores​ ​de​ ​PHP​ ​se​ ​ven​ ​de​ ​la​ ​siguiente​ ​manera:

Una petición HTTP viene del navegador de un usuario, y llega al servidor Apache.
Apache crea un proceso separado para cada petición, ademas crea optimizaciones
para re utilizarlos de manera que se minimice la cantidad de procesos que tiene que
hace (crear procesos es relativamente lento). Apache llama a PHP y le dice que
archivo .php debe de ejecutar. el código PHP se ejecuta y hace llamadas blocking.
Llamas file_get_contents() en PHP y este mismo hace llamadas al sistema read() y
espera​ ​el​ ​resultado.

​ ​A​ ​continuación​ ​el​ ​código​ ​de​ ​ejemplo:

<?php

//​ ​bloqueo​ ​del​ ​archivo​ ​I/O

$file_data​​ ​=​ ​file_get_contents(‘/path/to/[Link]’);

//​ ​bloqueo​ ​de​ ​la​ ​red​ ​I/O

$curl​​ ​=​ ​curl_init(​'[Link]
$result​​ ​=​ ​curl_exec(​$curl​);

//​ ​Más​ ​bloqueo​ ​de​ ​red​ ​I/O

$result​​ ​=​ ​$db​->query(​'SELECT​ ​id,​ ​data​ ​FROM​ ​examples​ ​ORDER​ ​BY​ ​id​ ​DESC​ ​limit​ ​100'​);

?>

Y​ ​una​ ​imagen​ ​para​ ​ejemplificar​ ​cómo​ ​esto​ ​se​ ​integra​ ​con​ ​el​ ​sistema.
Es bastante sencillo, un proceso por petición. Las llamadas I/O solamente bloquean.
La ventaja es que es bastante simpLe y funciona. La desventaja es que si intentas
procesas 20,000 peticiones de clientes concurrentemente el servidor en el que está
corriendo tu aplicación dejará de funcionar apropiadamente o se detendrá por
completo. Está solución no escala muy bien, debido a que las herramientas que
provee el kernel para lidiar con altos volúmenes de I/O no son usadas. Además,
correr procesos separados para cada petición tiende a usar muchos recursos del
sistema, especialmente memoria, lo cual es lo primero que resulta insuficiente en un
escenario​ ​como​ ​el​ ​presentado.

● Java.
Java utiliza un concepto llamado multithreading, el cual está construido en el
lenguaje, lo cual era especialmente innovador cuando Java entró por primera vez al
mercado.

La mayoría de los servidores Java lo que hacen es comenzar un nuevo thread de

ejecución por cada petición que entra al servidor y después en este mismo thread
llama​ ​a​ ​la​ ​función​ ​que​ ​el​ ​desarrollador​ ​Java​ ​escribió.

A​ ​continuación​ ​un​ ​ejemplo​ ​de​ ​código​ ​de​ ​I/O​ ​en​ ​un​ ​Servlet​ ​de​ ​Java:

public​​ ​void​​ ​doGet​(HttpServletRequest​ ​request,

HttpServletResponse​ ​response)​ ​throws​​ ​ServletException,​ ​IOException
{

//​ ​bloqueo​ ​de​ ​archivo​ ​I/O

InputStream​ ​fileIs​ ​=​ ​new​​ ​FileInputStream(​"/path/to/file"​);

//​ ​bloqueo​ ​de​ ​red​ ​I/O

URLConnection​ ​urlConnection​ ​=​ ​(​new
URL(​"[Link]
InputStream​ ​netIs​ ​=​ ​[Link]();

//​ ​Más​ ​bloqueo​ ​de​ ​red​ ​I/O

[Link](​"..."​);
}

El método doGet corresponde a una petición y es ejecutado en su propio thread, en

lugar de procesos separados para cada petición lo cual requiere su propia
memoria,tenemos un thread separado. Esto tiene algunas ventajas, como la
posibilidad de compartir el estado, los datos en caché, etc. entre los threads debido a
que pueden acceder a la memoria de otros threads, pero el impacto de cómo
interactúa con la organización de procesos es casi idéntico a lo que se vio con PHP
previamente. Cada petición genera un nuevo thread por cada distinta operación I/O
hasta que la petición sea completada exitosamente. Los threads son almacenados
para minimizar el costo de creacion y destruccion de los mismos, pero aún así, miles
de conecciones significa que habrán miles de threads lo cual es malo para el
organizador​ ​de​ ​procesos.

En la actualización 1.4 de Java y con otra actualización importante en la version 1.7,

Java obtuvo la habilidad de hacer llamadas non-blocking I/O. La mayoría de las
aplicaciones actuales escritas en Java sin embargo siguen funcionando de la manera
descrita anteriormente. Algunos servidores web Java intentan utilizar esta
característica​ ​de​ ​distintas​ ​maneras​ ​pero​ ​aún​ ​así​ ​no​ ​es​ ​muy​ ​utilizado​ ​en​ ​la​ ​actualidad.

Java nos acerca a una buena funcionalidad I/O, definitivamente tiene muy buena
funcionalidad para realizar llamadas non-blocking, aún así no resuelve el problema
de qué sucede cuando tienes una aplicación con una fuerte carga de llamadas I/O y
los​ ​threads​ ​se​ ​comienzan​ ​a​ ​bloquear.

● [Link].
Cuando se trata de mejores prácticas de I/O [Link] se viene a la mente de muchos
desarrolladores, ya que si alguna vez has tenido un curso introductoria a esta
herramienta lo primero que se menciona es que es “non-blocking” y que maneja el
I/O muy eficientemente. Esto es cierto en un sentido general, pero es muy importante
adentrarnos en los detalles de cómo maneja [Link] el I/O para poder comprender
que​ ​lo​ ​hace​ ​tan​ ​eficiente.

Esencialmente, el cambio de paradigma que [Link] implementa es que en lugar de

decir “escribe tu código aquí para manejar una petición”, dice “escribe tu código aquí
para comenzar a manejar una petición”. Cada vez que necesites hacer algo que
involucre I/O, haces una petición que te da una función callback a la cual [Link]
llama​ ​cuando​ ​se​ ​haya​ ​completado.

El código de [Link] para hacer una operación I/O por lo general se ve de la

siguiente​ ​manera:

​ ​[Link](​function​(request,​ ​response)​ ​{
[Link](​'/path/to/file'​,​ ​'utf8'​,​ ​function​(err,​ ​data)​ ​{
[Link](data);
});
});

Como podemos observar, hay dos funciones callback en este ejemplo. La primera se
llama cuando comienza la petición, y la segunda se llama cuando los datos del
archivo​ ​están​ ​disponibles.

Lo que esto hace es básicamente darle a [Link] la oportunidad de eficientemente

manejar el I/O en medio de estas llamadas. Un escenario donde sería aún más
relevante es cuando se está haciendo una llamada a base de datos en [Link],
básicamente funciona de la siguiente manera: Comienzas la llamada a la base de
datos, y le das a [Link] una función con un callback, realiza las operaciones I/O por
separado utilizando llamadas [Link] y después invoca a la función callback
cuando los datos de la petición están disponibles. Este mecanismo de poner en cola
las llamadas I/O y dejar que [Link] se encargue de estas llamadas se llama “Even
loop”​ ​(ciclo​ ​de​ ​eventos),​ ​y​ ​funciona​ ​bastante​ ​bien.
A pesar de que resulta muy eficiente [Link] ha sido muy criticado debido a que
todos los procesos los corre en un solo thread, es decir, no es posible hacer
multithreading​ ​con​ ​[Link].

[Link] fue creado explícitamente como un experimento de procesamiento

asíncrono. La teoría era que hacer procesamiento asíncrono en un solo thread
puede proveer mucho mejor desempeño y escalabilidad con cargas de una
aplicación​ ​web​ ​que​ ​una​ ​implementación​ ​clásica​ ​basada​ ​en​ ​threads.

[Link] ha demostrado correcta esa teoría, ya que si no está realizando tareas muy
intensivas en el CPU puede soportar miles de conexiones concurrentes más que
apache​ ​o​ ​IIS​ ​u​ ​otros​ ​servidores​ ​basados​ ​en​ ​threads.
Una de las características principales de Go es que contiene su propio organizador.
En lugar de que cada thread de ejecución corresponda a un solo thread del sistema
operativo go utiliza un concepto que se conoce como “goroutines”. Y la rutina Go
puede asignar goroutines a un thread del sistema operativo y ejecutarlo, o
suspenderlo y que no esté asociado con el thread del sistema operativo, basado en
lo que la goroutine esté haciendo. Cada petición que viene de el servidor HTTP de
Go​ ​es​ ​manejada​ ​en​ ​una​ ​goroutine​ ​separada.

El​ ​diagrama​ ​de​ ​cómo​ ​funciona​ ​el​ ​organizador​ ​es​ ​el​ ​siguiente:
Y​ ​este​ ​es​ ​un​ ​ejemplo​ ​de​ ​código​ ​Go:

func​​ ​ServeHTTP(w​ ​[Link],​ ​r​ ​*[Link])​ ​{

//​ ​Llamada​ ​non-blocking​ ​de​ ​red.

rows,​ ​err​ ​:=​ ​[Link](​"SELECT​ ​..."​)

for​​ ​_,​ ​row​ ​:=​ ​range​​ ​rows​ ​{

//​ ​Hacer​ ​algo​ ​con​ ​cada​ ​fila,
//​ ​cada​ ​petición​ ​está​ ​en​ ​un​ ​goroutine
}

[Link](...)​ ​//​ ​escritura​ ​de​ ​la​ ​respuesta

En esencia, la ejecución de Go está haciendo algo similar a lo que [Link] está

haciendo, la diferencia es que no estás atado a un solo thread cómo en [Link]. Lo
cual puede resultar en muchos errores que presentan implementaciones
tradicionales de threading cómo el exceso de threads lo cual puede acabar con la
memoria​ ​de​ ​un​ ​servidor​ ​en​ ​muy​ ​poco​ ​tiempo.

● Problemas​ ​de​ ​threading.

Los threads parecen ser el mayor problema con aplicaciones que tienen que lidiar
con muchas peticiones al mismo tiempo, desde que se trabaja con múltiples threads
se han tenido problemas recurrentes, [Link] no sufre de estos problemas debido a
su​ ​falta​ ​de​ ​threads,​ ​lo​ ​cual​ ​le​ ​ha​ ​funcionado​ ​bastante​ ​bien.

De hecho, tener demasiados threads puede afectar negativamente el desempeño de

una aplicación. El impacto puede llegar de dos maneras. Primero, puede existir
demasiada partición del trabajo entre distintos threads y esto le da muy poco trabajo
a cada thread, de manera que los recursos utilizados para iniciar y terminar cada
thread pueden llegar a ser mayores a los recursos que consume la ejecución del
trabajo​ ​dentro​ ​de​ ​cada​ ​thread.

El problema también es cuando los threads del software chocan con los threads del
hardware, es decir, cuando hay más threads de software que threads de hardware, el
sistema operativo utiliza una organización llamada round robin. El organizador le da
a cada thread de software un turno corto llamado “rebanada de tiempo”, para ser
ejecutado en un thread de hardware. Cuando una rebanada de tiempo de un thread
de software se acaba, el organizador suspende el thread para poder ejecutar otre
thread de software en el mismo thread de hardware. El thread de software deja de
ejecutarse​ ​hasta​ ​que​ ​se​ ​le​ ​asigna​ ​otra​ ​rebanada​ ​de​ ​tiempo.

Las “rebanadas de tiempo” aseguran que los threads de software progresen. De otra
manera, algunos threads de software pueden acaparar todos los threads de
hardware y dejar sí tiempo de ejecución a otros threads de software. Sin embargo
está asignación equitativa de threads de hardware produce problemas. Cuando hay
muchos​ ​threads​ ​de​ ​software,​ ​el​ ​rendimiento​ ​de​ ​la​ ​aplicación​ ​baja.
CAPÍTULO​ ​V.​ ​DISCUSIÓN

Conclusiones.
[Link] ha surgido en años recientes como una herramienta para el desarrollo de
aplicaciones web con el objetivo principal de hacer aplicaciones en tiempo real y
evitar​ ​el​ ​modelo​ ​de​ ​bloqueo​ ​de​ ​aplicaciones​ ​web​ ​tradicionales.

El procesamiento asíncrono de [Link], el cual comenzó como un experimento en el

cual se intentaba probar que el uso de un solo thread con procesamiento asíncrono
podía resultar en un alto desempeño resultó ser altamente exitoso no solo en
cuestiones de rendimiento sino también de escalabilidad, la cantidad de conexiones
concurrentes que puede soportar un servidor [Link] en comparación a servidores
que utiliza tecnologías más tradicionales es mucho mayor y tiene mucha mejor
tolerancia​ ​a​ ​fallos.

Sin duda alguna los casos de uso presentados en está investigación demuestra el
potencial​ ​de​ ​[Link]

[Link] ha demostrado ser una pieza fundamental en el camino al desarrollo

fullstack con javascript. A pesar de que no fue la primera herramienta que permite
escribir Javascript en el servidor, sin duda fue la primera que lo hacía con buenas
prácticas​ ​y​ ​mejor​ ​rendimiento​ ​que​ ​otras​ ​herramientas​ ​populares.

Espero que está tesina sirva en un futuro como una referencia de la historia, casos
de uso y comparación con otros lenguajes para el desarrollo web y de está manera
pueda ser útil para otros investigadores y/o alumnos que necesiten un conjunto de
datos acerca de [Link] que sean concretos y no tengan que ingresar a tantas
fuentes​ ​de​ ​información​ ​como​ ​sucedió​ ​en​ ​mi​ ​caso.

También espero que este trabajo de investigación cause curiosidad en los lectores
por el uso de la plataforma y atraiga a más desarrolladores y empresas al mundo de
[Link]​ ​y​ ​al​ ​mundo​ ​del​ ​opensource.
Referencias​ ​bibliográficas.

Tomislav​ ​Capan,​ ​“Why​ ​the​ ​Hell​ ​Would​ ​You​ ​Use​ ​[Link]”,​ ​2017,
Disponible​ ​en:
[Link]
de-js-4b053b94ab8e

Alejandro​ ​Hernandez,​ ​“[Link]:​ ​A​ ​Guide​ ​to​ ​the​ ​Why​ ​and​ ​How​ ​of​ ​Full-Stack
JavaScript”,​ ​2017,​ ​Disponible​ ​en:
[Link]

Amber​ ​Harris,​ ​“The​ ​Birth​ ​of​ ​[Link]:​ ​Where​ ​Did​ ​it​ ​Come​ ​From?​ ​Creator
Ryan​ ​Dahl​ ​Shares​ ​the​ ​History”,​ ​2013,​ ​Disponible​ ​en:
[Link]
me-from-creator-ryan-dahl-shares-the-history/

Mark​ ​F.​ ​Adam,​ ​“The​ ​History​ ​and​ ​Impact​ ​of​ ​[Link]”,​ ​2017,​ ​Disponible​ ​en:
[Link]

Peter​ ​Wayner,​ ​“JavaScript​ ​conquers​ ​the​ ​server”,​ ​2011,​ ​Disponible​ ​en:

[Link]
[Link]

Cindy​ ​Sridharan,​ ​“Nonblocking​ ​I/O”,​ ​2017,​ ​Disponible​ ​en:

[Link]

Ferenc​ ​Hámori,​ ​“This​ ​is​ ​what​ ​[Link]​ ​is​ ​used​ ​for​ ​in​ ​2017​ ​-​ ​Survey
Results”,​ ​2017,​ ​Disponible​ ​en:
[Link]

The​ ​Linux​ ​Foundation,​ ​“Use​ ​cases”,​ ​2017,​ ​Disponible​ ​en:

[Link]

Aleks​ ​Pedchenko,​ ​“TOP​ ​6+1​ ​companies​ ​using​ ​[Link]​ ​in​ ​Production

”,​ ​2017,​ ​Disponible​ ​en:
[Link]
uction-9c9e0df4e8ab

Brad​ ​Peabody,​ ​“Server-side​ ​I/O​ ​Performance:​ ​[Link]​ ​vs.​ ​PHP​ ​vs.​ ​Java
vs.​ ​Go”,​ ​2017,​ ​Disponible​ ​en:
[Link]
va-go
Glosario.
API: ​Aplication Programming Interface, Interfaz de Programación de Aplicaciones,
es un conjunto de subrutinas, funciones y procedimientos (o métodos, en la
programación orientada a objetos) que ofrece cierta biblioteca para ser utilizado por
otro​ ​software​ ​como​ ​una​ ​capa​ ​de​ ​abstracción.

Blocking: ​Métodos que deben de terminar para que pueda comenzar la ejecución
del​ ​siguiente​ ​método.

Non-blocking: ​Métodos que no bloquean la ejecución de otros o bloquean por una

cantidad​ ​de​ ​tiempo​ ​muy​ ​corta.

I/O:​ ​Input/Output,​ ​operaciones​ ​que​ ​requieren​ ​un​ ​ingreso​ ​o​ ​egreso​ ​de​ ​datos.

Frontend: ​Tipo de programación que involucra la parte del cliente, esté se puede
referir​ ​tanto​ ​a​ ​cliente​ ​móvil​ ​como​ ​web.

Backend: ​Tipo de programación que se refiere a la parte del servidor, es la que se

encarga​ ​de​ ​ejecutar​ ​métodos​ ​de​ ​obtención​ ​y​ ​envío​ ​de​ ​datos.

Big​ ​Data:​ ​Manejo​ ​de​ ​grandes​ ​cantidades​ ​de​ ​datos.

IoT: ​Internet of Things (Internet de las cosas), se refiere a los dispositivos

electrónicos no clasificados como una computadora o celular en el sentido
convencional​ ​que​ ​están​ ​conectados​ ​al​ ​internet.

Analytics:​ ​Análisis​ ​de​ ​datos.

JSON: ​JSON, acrónimo de JavaScript Object Notation, es un formato de texto ligero

para el intercambio de datos. JSON es un subconjunto de la notación literal de
objetos de JavaScript aunque hoy, debido a su amplia adopción como alternativa a
XML,​ ​se​ ​considera​ ​un​ ​formato​ ​de​ ​lenguaje​ ​independiente.

DOM: ​Document Object Model o DOM ('Modelo de Objetos del Documento' o

'Modelo en Objetos para la Representación de Documentos') es esencialmente una
interfaz de plataforma que proporciona un conjunto estándar de objetos para
representar documentos HTML, XHTML y XML, un modelo estándar sobre cómo
pueden combinarse dichos objetos, y una interfaz estándar para acceder a ellos y
manipularlos.

Framework: ​Un framework, entorno de trabajo o marco de trabajo​ es un conjunto

estandarizado de conceptos, prácticas y criterios para enfocar un tipo de
problemática particular que sirve como referencia, para enfrentar y resolver nuevos
problemas​ ​de​ ​índole​ ​similar.

SDK: ​Un kit de desarrollo de software es generalmente un conjunto de herramientas

de desarrollo de software que le permite al programador o desarrollador de software
crear una aplicación informática para un sistema concreto, por ejemplo ciertos
paquetes de software, frameworks, plataformas de hardware, computadoras,
videoconsolas,​ ​sistemas​ ​operativos,​ ​etcétera.