Foco de atención en Módulo npm de StrongLoop – Construir, desplegar y gestionar procesos Node.js

Editors Note: This post by Alex Gorbatchev was translated courtesy of Carlos Eduardo Carcamo Mendoza

Quiero tomarme un momento para hablar un poco sobre cómo desplegar tu aplicación Node.js. Este tema en general esta bastante bien definido pero no existen muchas herramientas hechas para Node. He visto aplicaciones Node.js desplegadas por Capistrano, y si, funcionan pero como desarrollador JavaScript eso no va del todo bien conmigo y preferiría algo más familiar, algo que se ajuste a mi infraestructura, algo que esté escrito en el lenguaje con el que estoy bien familiarizado y que cuando las cosas vayan mal pueda comprender los mensajes de error sin hacer una búsqueda extensiva.

indiana-jones-sand-bag

Presentando strong-pm

Introducción a strong-pm! Pero antes… ¿Como se despliega generalmente una aplicación Node.js? El código es enviado vía git push o git pull a uno o varios servidores. Luego cada servidor crea una construcción completa y hace un npm install. Posteriormente cada servidor procede a descargar y generar todas las dependencias NPM requeridas. Generalmente este es un proceso que consume bastante tiempo, sin mencionar que le cuesta una buena cantidad de dinero a la estimada gente de NPM Inc.

StrongLoop ha desarrollado una muy buena solución que consiste en tres módulos separados, cada uno haciendo lo suyo para darte un ligero flujo de trabajo para generar/desplegar/ejecutar listo para usarse.

  • strong-build – crea un elemento de construcción para tus proyectos (de otra manera un repositorio GIT) .
  • strong-deploy – envía el elemento de construcción generado por strong-build a una instancia en ejecución de strong-pm.
  • strong-pm – recibe el elemento de construcción y lo ejecuta localmente garantizando el tiempo de actividad.

Vamos a ver cada uno de ellos con algunos detalles para tener una mejor comprensión del trabajo involucrado en cada paso. Para una documentación técnica más completa por favor visita las páginas de GitHub de los links anteriores.

strong-build

strong-build es el primero de dos pasos en el camino para hacer tus ciclos de despliegues más sencillos. Esto es lo que hace:

  • Instala dependencias, ejecuta pasos de construcción personalizados, y reduce las dependencias de desarrollo, todo sin afectar tu estructura de código fuente.
  • Modifica los archivos de configuración package.json y .npmignore para que las dependencias sean empaquetadas.
  • Crea un paquete npm de la construcción o hace un commit de la construcción en una rama GIT de despliegue (basado en los ajustes seleccionados).

Por supuesto, todas las opciones acá (como en otros módulos) son totalmente configurables. Cada paso puede ser ejecutado mediante un comando individual y ejecutando strong-build los ejecuta a todos en secuencia: install, bundle, pack y commit. Al final podrías obtener un GIT deploy o bien un archivo TAR listo para ser enviado a la máquina destino.

Algo muy importante a tener en mente es que si tu aplicación utiliza cualquier módulo nativo (que es probable que lo haga), no querrás compilarlos durante la construcción a menos que el equipo donde estas ejecutando la construcción coincida con el servidor en términos de sistema operativo y librerías. Por defecto strong-build no ejecuta scripts NPM por lo tanto no ocurre una compilación. Esto quiere decir que puedes empaquetar y construir tus proyectos en tu laptop y desplegarlas con seguridad a producción asumiendo que todas las bibliotecas requeridas están instaladas en el servidor. Por supuesto puedes cambiar esto con la opción -- scripts que le indica a strong-build que ejecute los scripts NPM.

strong-deploy

Después que has ejecutado strong-build y tienes listo un elemento de construcción, el módulo strong-deploy hace la tarea de enviar la construcción a la instancia en ejecución de strong-pm. strong-deploy espera una ubicación de destino y la enviará a través de HTTP o SSH.

strong-pm

El corazón de todo el sistema es el módulo strong-pm. Se supone que debe estar funcionando como un servicio para el cual es sencillo generar archivos de sistema apropiados al SO. Luego que strong-deploy termine de enviar el nuevo elemento de construcción, strong-pm se prepara usando el comando prepare y posteriormente inicia la aplicación con el comando run.

Cuando se reinicia una aplicación en ejecución, strong-pm gentilmente tratará de detenerla e iniciar una nueva. Por defecto el clustering se basa en el número de núcleos disponibles del CPU.

Resumen

En el servidor:

  • Instalar strong-pm como un servicio del sistema usando el comando incluido sl-pm-install (consulta sl-pm-install --help para ver las opciones disponibles).
  • Iniciar el servicio.

En la máquina de construcción:

  • Ejecuta strong-build para generar un elemento de construcción.
  • Ejecuta strong-deploy para enviar el elemento a la instancia strong-pm en ejecución.

Desarrolla APIs visualmente con StrongLoop Arc

Metrics

StrongLoop Arc es una Interfaz de Usuario Gráfica para la Plataforma StrongLoop API, que incluye LoopBack, que complementa las herramientas de línea de comandos slc para desarrollar APIs rápidamente y permitir que estas se conecten a los datos. Arc también incluye herramientas para construir, perfilar y monitorear aplicaciones Node. Para comenzar solo se necesitan unos cuantos pasos sencillos!

 

Autenticación de dos factores con LoopBack

Editors Note: This post by Jordan Kasper was translated courtesy of Carlos Eduardo Carcamo Mendoza

Antes de comenzar con en el código y guiarte a través de él, quiero hablar sobre mi motivación para escribir este post. Recientemente di una charla en Confoo developer conference en Montreal. Si no has estado ahí, es un torbellino de nuevas tecnologías, teoria de datos complejos, útiles habilidades de software  y, sólida y práctica información para tecnólogos de todo tipo y niveles. Los últimos dos años he tenido el placer de asistir (y hablar) y siempre encuentro gran cantidad de buena información y buenas oportunidades de networking. Este año fue la primera vez que StrongLoop se hizo presente, pero teniendo en cuenta la relación hecha con ambos, usuarios de LoopBack y potenciales socios nuevos como Riak and Nexmo, espero que tengamos la oportunidad de volver el próximo año.

¿Que es LoopBack? Es un Framework open source para la creación rápida de APIs con Node y permite que estas se conecten a los datos.

En base a la frecuencia de sesiones que le rodean y las conversaciones en los pasillos, te puedo decir con confianza que la gran novedad fueron las APIs. Desde los Frameworks de código hasta la autenticación para monitorear, todo el mundo se esta inclinando en esa dirección. En efecto, la popularidad de nuestra presentación en Node Submmit a cargo de Al Tsang ha demostrado ese impacto en la comunidad Node.js y más allá. Y Node está bien equipado para dicha tarea.

¿Que hay sobre la autenticación?

LoopBack ya cuenta con Autenticación y Autorización. Hay una clase User que puedes utilizar directamente o extenderla para que se adapte a tus necesidades. Cada Modelo en LoopBack puede tener también una gran variedad de reglas de control de accesos incorporadas utilizando los roles de usuarios existentes. No voy a tratar a profundidad este mecanismo, pero puedes leer más en el link anterior. En su lugar, me voy a enfocar en algunas ideas de una de las sesiones en Confoo: Chris Cornutt’s “Beginner’s Guide to Alternative Authorization”.

Puedes revisar las diapositivas de su charla en su página de SpeakerDeck, pero déjame darte un breve resumen: Hay muchos diferentes mecanismos de autenticación, y todos ellos tienen sus propios matices, beneficios y problemas. Esta sesión fue solo una visión general de muchos de esos mecanismos, pero me hizo pensar en la Autenticación integrada en LoopBack y como un desarrollador podría hacerla más segura usando algo como un proceso multi-factor.

Así, sin mas preambulos, veamos como podemos extender el Sistema LoopBack de inicio de sesión existente para usar autenticación de dos factores con envío de código sms en función del tiempo.

En función de tiempo y SMS

Ciertamente hay muchos mecanismos de autenticación mejorados, como lo demuestra la presentación de Chris, pero debemos enfocarnos en algo ampliamente aplicable a aplicaciones web y en algo que podamos hacer en un solo post! Con la abundancia de APIs SMS, el envío de un código SMS en función del tiempo debería ser sencillo. ¿Porque en función del tiempo? Bueno, queremos que el usuario solo pueda usar este código cuando este iniciando sesión, y queremos que sea inservible luego de un conveniente lapso de tiempo (¿Tal vez 60 segundos?).

El proceso básico de inicio de sesión cambiará de un simple formulario de entrada de email y contraseña a un proceso de 2.5 pasos:

  1. El usuario solicita un código de dos factores…
    • El usuario deberá introducir su email y contraseña, que serán verificados.
    • El sistema enviará al usuario un código único a su dispositivo móvil.
  2. El usuario deberá introducir el código en la interfaz para completar el proceso ‘log in’.

Ok, estoy convencido… ¿Como lo implemento?

En primer lugar, cree un nuevo proyecto LoopBack (Necesitarás tener instalado el controlador StrongLoop: npm install -g strongloop):

$ slc loopback

Sigue las instrucciones para crear tu aplicación, luego crea un nuevo modelo que extienda la clase User — Yo Llamé a la mía “Employee”. Dentro de nuestro nuevo modelo Employee vamos a crear dos métodos remotos nuevos para nuestro proceso de 2(.5) pasos. Me voy a saltar directamente a los métodos en concreto, pero puedes leer sobre como crearlos en el vínculo de la oración anterior.

Acá esta nuestra función para solicitar un nuevo código de dos factores de tiempo limitado. Ten en cuenta que esto hace 3 cosas básicas: encontrar al usuario, comprobar su contraseña, y enviarle un código. He dejado de lado un montón de control de errores, pero puedes verlo en el repositorio del ejemplo. También estamos usando la librería speakeasy para generar nuestros tokens, así que vamos a requerir eso primero (Asegurate de instalarla como dependencia: npm install --save speakeasy).

Una vez que al usuario se le haya enviado su código de verificación de tiempo limitado necesitará un punto de conexión para enviarlo y completar el proceso de inicio de sesión. Ten en cuenta que este código expira rápidamente (30 segundos es el valor por defecto de speakeasy), así que nuestra Interfaz de Usuario debe estar preparada para aceptar el código de inmediato (sin pasar por múltiples páginas!).

De nuevo, por motivos de brevedad de este post, en el siguiente ejemplo he dejado fuera un montón de revisiones. Asegurate de revisar todo! 

Genial! ya casi hemos terminado con la parte del lado del servidor. Todo lo que necesitamos es hacer públicos los dos nuevos métodos remotos, de lo contrario tendrías que estar logueado para iniciar sesión. 🙂

Abre el archivo generado /common/models/employee.json y actualiza el objeto acls para permitir acceso de $everyone para ambos métodos:

¿Que hay sobre la integración SMS?

Puedes haber notado que hay un comentario [TODO] en el método Employee.requestCode() para enviar código vía sms al usuario. No he incluido ese código porque éste requerirá alguna integración y configuración de cuentas de tu parte. Dicho esto, muchas de las empresas de SMS y APIs de voz poseen APIs REST propias muy sencillas que puedes usar. De hecho, podría ser tan simple como esto (si estuvieras usando Nexmo):

Enviar Notificaciones 

A pesar que esta fuera de alcance de este artículo, en el caso que las notificaciones SMS no sean lo tuyo y has desarrollado ya una aplicación móvil nativa, podrías también enviar el código de dos factores usando el componente LoopBack’s push notification!.

Eso es todo en el lado del Servidor! En este punto podrías ejecutar slc run e ir a http://localhost:3000/explorer y ver tu nuevo modelo y los métodos remotos personalizados. Sin Embargo, no son muy interesantes sin verlos en acción. Así que vamos a crear una interfaz ligera para ver como encaja todo.

two-factor-explorer

Un ligero formulario de acceso

Primero, es necesario seguir las instrucciones de aquí para añadir una configuración middleware para servir archivos estáticos desde el directorio /client; luego podemos añadir un nuevo archivo HTML dentro de ese directorio. Puedes usar el archivo desde mi repositorio de ejemplo, pero acá esta la parte importante, el formulario:

two-factor-form 

Ahora podemos agregar una etiqueta <script> al final del código de nuestra interfaz de usuario para llamar a los puntos de conexión. Vamos a usar algunas llamadas Ajax sencillas y manipulaciones DOM para lograr nuestro objetivo, pero no te preocupes por los detalles, tu interfaz de usuario puede ser muy diferente. Esto es más para demostrar cómo usar los puntos de conexión que hemos creado.

Cuando el usuario envía el formulario, nosotros vamos a revisar si tiene un código de verificación, si no lo tiene, solicitaremos uno para ellos. Una vez tengan un código, vamos a enviar la segunda llamada a la API para completar el proceso de inicio de sesión.

Ten en cuenta que el código a continuación ha sido reducido por motivos de brevedad! puedes ver el código JavaScript completo de la interfaz de usuario en el repositorio de ejemplo. 

Muéstrame la aplicación! 

Puedes acceder al código completo de la aplicación de ejemplo en GitHub, sólo debes clonar el repositorio (o descargar el código), ejecutar npm install desde una consola para instalar todas las dependencias, luego ejecuta slc run para iniciar la aplicación! Dirígete a http://localhost:3000 para ver la aplicación en acción! Querras tener la consola abierta, dado que no tenemos la integración SMS conectada, el código de verificación será  impreso en la consola del servidor. 

two-factor-code

No puede ser!, ¿eso es todo? 

Realmente lo es! con solo un par de métodos remotos podemos convertir una sencilla aplicación LoopBack en un seguro sistema de autenticación de dos factores. Por supuesto, es importante saber cual mecanismo de autenticación es el indicado para los usuarios de tu aplicación. Adicionalmente, necesitarás agregar los controles de acceso adecuados a todos los Metodos de tu API. Echa un vistazo al tutorial en nuestra documentación oficial para más información de como configurarlo.

¿Necesitas Más?

Si este post solo te despertó el apetito por más información sobre LoopBack, Capas de control de acceso, APIs, Autenticación, o incluso SMS via Node.js entonces sigueme en Twitter (@jakerella)! o deja un comentario en el post, mantengamos viva la discusión sobre seguridad.

Desarrolla APIs visualmente con StrongLoop Arc

StrongLoop Arc es una Interfaz de Usuario Gráfica para la Plataforma StrongLoop API, que incluye LoopBack, que complementa las herramientas de línea de comandos slc para desarrollar APIs rápidamente y permitir que estas se conecten a los datos. Arc también incluye herramientas para construir, perfilar y monitorear aplicaciones Node. Para comenzar solo se necesitan unos cuantos pasos sencillos!

 

Creando mejores Módulos npm con Travis y Coveralls

Editors Note: This post by Valeri Karpov was translated courtesy of Carlos Eduardo Carcamo Mendoza

Parte de lo que hace a Node.js tan poderoso es la amplia variedad de módulos de alta calidad en npm. Pero, muchos módulos no toman ventaja de las herramientas de prueba como Travis y Coveralls. Travis es una ligera herramienta de integración continua que ejecuta pruebas en cada commit a tu repositorio en GitHub, incluso en pull requests. Coveralls genera reportes de cobertura de pruebas que puedes integrar con Travis. Estas herramientas mejoran el flujo de trabajo, haciendo las revisiones de pull requests más sencillas, y hacen que los usuarios estén más seguros de la calidad de tus módulos. En este articulo, aprenderás como integrar estas herramientas con mocha e istanbul en un simple proyecto Node.

Este ejemplo usará una implementación JavaScript del ya conocido desafío de programación “fizzbuzz”. Fizzbuzz esta lejos de ser un modulo complejo, pero es lo suficientemente completo para obtener resultados reales de cobertura de pruebas. Para continuar con este ejemplo, haz un fork en github. El código en cuestión es el siguiente:

El código del modulo no es particularmente interesante. Probarlo es una tarea más sutil. La mayoría de las practicas modernas de pruebas se basan en la noción de complejidad ciclotímica. En otras palabras, cobertura de prueba al 100% significa que tus pruebas ejecutan cada ruta posible del código. El ejemplo Fizzbuzz de arriba tiene 10 rutas de código posibles (o “ramas” en la jerga de Coveralls). Cada sentencia if aporta 2 rutas de código, excepto el que tiene &&, que aporta 4. Por ejemplo, si usted fuera a sustituir

con

Solo habrán 8 ramas.

Configurando pruebas con Mocha y produciendo salidas de cobertura

El primer paso es obtener salidas de cobertura de pruebas localmente. Existen varios buenos Frameworks de prueba y herramientas de cobertura disponibles en npm. Pero, mis herramientas elegidas son el Framework de pruebas Mocha e Instanbul para cobertura de pruebas. Para este tutorial usted puede usar cualquier framework de prueba que guste, pero encuentro a mocha ser sensato por defecto. Primero, agregue mocha e istanbul a sus devDependencies en package.json.

También debe agregar una secuencia de comandos de prueba a su package.json, así puede ejecutar las pruebas con el comando npm tests.

Ahora, aquí hay algunas pruebas con mocha para el módulo FizzBuzz. Mocha usa una sintaxis estilo BDD (behavior-driven development), lo que significa que describe() e it() corresponden aproximadamente a “suites” y “tests” en frameworks de pruebas más convencionales como JUnit.

Ejecute estas pruebas con npm tests y usted debería obtener un informe de pruebas simple.

Ahora, la pregunta es, ¿Como puede obtener una salida de cobertura? Ahí es donde entra istanbul. Istanbul provee un ejecutable simple que envuelve su comando de pruebas y produce salidas Lcov por defecto. Añada un script test-travis a sus scripts en package.json como se muestra a continuación.

El script puede parecer intimidante, pero es sencillo una vez que lo observe con cuidado.

El ejecutable ./node_modules/istanbul/lib/cli.js es el CLI empaquetado de istanbul. Puede también utilizar require() istanbul en sus scripts Node, pero el ejecutable es suficiente para este ejemplo. El CLI de istanbul toma una opción cover la cual le indica que produzca una salida de cobertura.

El resto del script test-travis configura mocha. En primer lugar, tome en cuenta que el script anterior utiliza el ejecutable _mocha, mientras que el script de prueba (test) utiliza ./node_modules/mocha/bin/mocha. Esta es una fuente común de confusión cuando los principiantes tratan de configurar istanbul y mocha. El ejecutable mocha bifurca un ejecutable por separado, _mocha, que es el que realmente ejecuta las pruebas. Si usted fuera a correr el ejecutable mocha a través de istanbul, usted no obtendría una salida de cobertura.

El – – significa el fin de las opciones que se pasan al ejecutable istanbul.

Todo después de – – será interpretado como una opción para el ejecutable _mocha.

Ahora que usted tiene el script test-travis, ejecútelo para ver la salida de cobertura de prueba.

Felicidades, usted tiene una prueba de cobertura al 100%! A continuación, usted va a configurar Travis para ejecutar este comando automáticamente en cada commit y pull request.

Ejecutando pruebas y generando salidas de cobertura con Travis

Travis es una herramienta que le permite ejecutar un script en cada GitHub commit. Usted puede utilizar Travis para ejecutar el script test-travis visto anteriormente. Además, usted puede configurar Travis para enviar la salida de cobertura a Coveralls.

Primeramente, si usted aun no tiene una cuenta en Travis, regístrese para obtener una. Luego añada un nuevo repositorio a Travis usando el botón “Add New Repository”.

Find the fizzbuzz-coverage repo and add it. Next, sign up for an account on Coveralls. Click on the “Add Repos” button and add fizzbuzz-coverage.

Para utilizar Travis, tu repositorio de github debe tener un archivo .travis.yml. Esto le indica a Travis como debe ejecutar las pruebas. Por ejemplo, el siguiente .travis.yml es el archivo para el repositorio fizzbuzz-coverage (menos una línea que usted aprenderá más adelante).

Este archivo debe parecer sencillo incluso si nunca antes ha trabajado con Travis. Esta configuración le indica a Travis que ejecute npm run-script test-travis en Node 0.10 y 0.11. Cuando usted especifica language: node.js, Travis se encarga de instalar Node, clonar su repositorio y ejecutar npm install por usted.

Ahora, ¿Como puede enviar las salidas de cobertura generadas por istanbul a Coveralls? Como casi todo en estos días, existe un modulo npm para esto. El modulo npm coveralls contiene un archivo ejecutable llamado coveralls.js que usted puede usar para enviar salidas a Coveralls. Para ello solo necesita agregar coveralls a su package.json:

y agregar una linea a su archivo .travis.yml.

Añadiendo insignias

Ahora que ha enlazado su repositorio para ejecutar pruebas en Travis y enviar datos de cobertura a Coveralls, probablemente se este preguntando como añadir esas bonitas insignias en su repositorio GitHub.

Travis y Coveralls proveen unos puntos de conexión a sus APIs que le permiten obtener estas representaciones de los estados de sus repositorios en formato SVG (o PNG). Para obtener el SVG para fizzbuzz-coverage, usted debe incluir las siguientes imágenes en una etiqueta <img>.

Puede obtener el estado creación (build status) y la información de cobertura (coverage info) para cualquier rama cambiando el parámetro de consulta branch en la url de la imagen. El siguiente es código markdown que genera las insignias para el GitHub README.

Conclusión

En este articulo, ha visto lo fácil que puede ser vincular sus módulos npm en Travis y Coveralls. La Integración continua y cobertura de código solía ser factible solo para los Googles del mundo, pero ahora incluso un pequeño modulo npm puede sacar ventaja de estas sofisticadas practicas de desarrollo. Espero ver que más autores de módulos npm tomen ventaja de estas excelentes herramientas y tomen en serio las coberturas de pruebas.

¿Qué sigue?

¿Listo para diseñar, implementar, monitorear y escalar sus APIs? De un vistazo a StrongLoop Arc, la primera Interfaz de Usuario para manejar el ciclo de vida completo de APIs Node.

¿Qué hay de nuevo en io.js 1.0 Beta? – Streams 3

Originally authored by Krisha Raman, translated by Alejandro Oviedo

Los streams de Node son una forma poderosa de construir módulos y aplicaciones que manejan grandes streams de data. La API de Streams ha pasado por varias revisiones y ha estado mejorando establemente. Los Streams 1 introducieron push-streams para permitir a los desarrolladores consumir data eficientemente. Los Streams 2 agregaron pull-streams en adición a push-streams para permitir casos de uso más avanzados, sin embargo, los dos estilos no pueden utilizarse juntos. Los Streams 3 resuelven este problema de una manera elegante y permite al mismo stream ser utilizado tanto en modo push cómo en modo pull. Los Streams 3 están disponibles en Node v0.11/v0.12 y io.js

Continua leyendo para entrar en los detalles.

Streams 1 (Push streams)

En la implementación original de streams un evento de data era generado todas las veces que la data estaba disponible en el stream.

Los desarrolladores podían usar pause() y resume() para controlar el flujo. Llamando pause()causaría que la implementación dejara de mandar eventos de data.

Read more

Qué hay de nuevo en Node.js v0.12 – Corriendo múltiples instancias en un sólo proceso

Una característica solicitada a menudo es la habilidad de incrustar Node.Js en otras aplicaciones, particularmente en maneras que permiten integrar con otras secuencias de eventos y mientras (“estás en ello”) con soporte para múltiples ejecuciones de contexto de Node: Es decir, la habilidad de tener múltiples instancias de Node coexistiendo pacíficamente dentro del mismo proceso. Imagina una aplicación node-webkit donde cada ventana corra con su propia instancia de Node que está aislado de todas las otras ventanas. O Node incrustado en un celular conmutador de red donde se está llevando a cabo la lógica de enrutamiento para multiples conecciones, pero en un solo proceso y tu no estas lejos demasiado lejos .

GitHub vino a nosotros necesitando de éste tipo de funcionalidad para el editor Atom que ellos estaban desarrollando. Es una orden muy alta porque Node comenzó como -y sigue siendo- una aplicación de un solo hilo de ejecución construida alrededor del concepto de una sola secuencia de eventos con cientos de variables globales que almacenan varios bits de estado.

Puedes imaginar cómo retroadaptar el hilo de ejecución de una manera segura a una base de código tal, es altamente una tarea propensa a errores y entonces, no fue eso lo que hicimos -o mejor dicho, no lo hemos hecho aún. Queríamos hacer este cambio accesible para los clientes y un paso más que ayudará a la toda la comunidad. De paso, si te encuentras necesitando algunos cambios en Node, pero sin tiempo para descubrir cómo hacer estos cambios, te podemos ayudar!

Presentando Contexto Múltiple

En lugar de ello, hemos hecho posible en Node v0.12 usar múltiples contextos de ejecución desde dentro de la misma secuencia de eventos. No te preocupes: Desde la perspectiva del usuario, no hay cambios visibles, todo aún trabaja como antes. Pero si eres un incrustador o un autor de complemento nativo, sigue leyendo!

El trabajo “contexto múltiple” que es obtenido en un commit 756b622 es primero y ante todo un trabajo limpio: Va sobre todas esas variables globales, eliminando a las que no necesitaban ser variables globales en primer lugar y cambiando a las que continúan en las propiedades en la ejecución del contexto. Eso aún no nos da hilos de ejecución seguros, pero es un primer paso importante.

La segunda parte es hacer que los componentes internos de Node sean conscientes de la existencia de múltiples contextos de ejecución. En todas partes el C++ en tiempo de ejecución hace un llamado al V8 VM, se necesita asegurarse de que primero entra en el contexto correcto.

Un ejemplo rápido:

En terminos de ejecución, se vería algo como esto:

Entre las llamadas al VM, es posible que el contexto de ejecución cambie. Por lo tanto es esencial que connect() recuerde el contexto actual y que el llamado a onconnect() lo restaure. Fallar al hacerlo puede conllevar a errores difíciles de reparar.

Afortunadamente Node se ocupa de ello automáticamente; incrustadores o autores complementos nativos no necesitan preocuparse al respecto a menos que hagan llamados a VM con 8::Function::Call() en vez de node::MakeCallback().

Si eres un autor de complemento y quieres hacer tu complemento consciente del contexto, esto es lo que necesitas hacer:

Después:

Tu analizador consciente del contexto es llamado una vez por cada contexto que el incrustador creó. Aún no existe ninguna función de limpieza por contexto.
Eventualmente, node::AtExit() llenará ese papel pero por ahora sigue un evento por proceso. Si eso es un problema para tí por favor envía un informe aquí.

Convertir variables globales a propiedades por contexto. Hay varias maneras de hacer eso pero una opción es solicitar el índice de datos de un incrustador para tí y almacenar todo allí.

Todavía no hay registros globales para índices, así que es posible que haya conflictos. ¿Alguien quiere probar su suerte en un parche? Mientras tanto escoge un número aleatorio muy grande (entre el 2^10 y 2^16) pero no te vayas por la borda: V8 usa una matriz no-dispersa como almacenamiento de respaldo para índices incrustadores. Solicitar 1<<29 como tu índice consumirá mucha memoria!

Cuánto más falta para terminar?

Todavía hay algunos bordes ásperos que necesitan ser pulidos: process.chdir() cambia el directorio de todos los contextos y no sólo el contexto de la llamada, cargar complementos desde múltiples contextos aún tiene algunos bordes de casos y así sucesivamente. Pero eso es escupir y pulir. El marco básico esta en su lugar y esta siendo usado exitosamente por la compañía que patrocina el esfuerzo del contexto múltiple. Lo que es más, que allana el camino para unos correctos hilos de ejecución múltiple y tenencia múltiple. Eso es improbable que pase antes de Node v0.12, pero tal vez lo veremos en en Node v1.0 u otra versión. -sólo retanos!

Usa StrongOps para monitorear aplicaciones en Node

¿Listo para comenzar a monitorear bucles de eventos, administrar clusters de Node e investigar fugas de memoria? Hemos hecho que sea muy fácil iniciar con StrongOps ya sea localmente o con tu servicio en tu nube favorito, con un simple comando de npm.
Screen Shot 2014-02-03 at 3.25.40 AM

¿Qué sigue?

*Nota del editor: Robert Wang escribió con esta aclaración cómo node-webkit trabaja en lo que respecta al ejemplo que citamos “Diferentes ventanas de node-webkit comparte una misma instancia de Node siempre y cuando están en el mismo proceso renderizador, que es el caso por defecto. El programador puede elegir abrir una ventana en un nuevo proceso renderizador pasando la opción de “new-instance”, en cuyo caso se inicia una nueva instancia de Node.”