Getting Started with Node.js for the PHP Developer

You’re a PHP developer.  I get it.  So am I.  My journey to PHP didn’t take the normal road that most PHP developers travel in their quest for the perfect programming language.  I initially started as Java Developer and spent roughly 10 years living in that land.  I was one of those die hard Java developers that when PHP would get introduced into a conversation, I would start spouting off things like enterprise, scalability and other nonsense.

I started working on an open source project that needed a social web front-end about 5 years ago and the team needed to choose a programming language for the site.  I explored Java and most other languages but settled on PHP  for a number of reasons.  It was tough to swallow my pride and start coding in PHP but what happened during that project was nothing short of a miracle.  I fell in love with the language and began using it for as many projects that I could find while leaving my Java roots in the dust.  PHP has served me well over the last 5 years but I was still searching for that holy grail of a programming language that is fast to develop in, has enterprise backing, is performant and scalable while also providing a strong community of developers.  I believe that Node.js satisfies all of my requirements while still being a fast growing and evolving language.

The first thing you need to understand is that Node.js is not just for the hipster developers or early adopters.  It is in use by some of the most highly trafficked website on the Internet today and is continuing to win over developers hearts and mind.  It is truly at a point where you can trust it for even the most complicated of systems.

Node.js is JavaScript

If you are thinking you need to learn a whole new language to be productive with Node.js, you are probably wrong.  Most developers are already familiar with JavaScript and that is the language and semantics that you will be working with when coding in Node.js.  In fact, a recent article published by Red Monk that tries to make sense of github projects to determine the most popular languages has JavaScript as the King.  The top three languages are as follows:

  1. JavaScript
  2. Java
  3. PHP

Given the popularity of JavaScript and its widespread adoption across our industry, if you are not already familiar with it, it’s probably time to buckle down and start learning it.

If Node.js just uses JavaScript, what exactly is it?

In a nutshell, Node.js is a platform for server side activities.  It uses the Javascript programming language and has a plethora of libraries available as npm modules.  You can think of these npm modules as library dependencies that may be satisfied with Composer if you are coming from PHP land.  In fact, the default dependencies management system for PHP (Composer) was inspired by Node.js according the official site.  Chances are, if you need a bit of functionality and don’t fancy writing all of the code yourself, there is an npm module available that already provides the features you are looking for.

Node applications are normally implemented when you need to maximize efficiency by utilizing non-blocking I/O and asynchronous events.  One gotcha for PHP Developers to know is that Node.js applications run in a single thread. However, backend Node.js code uses multiple threads for operations such as network and file access.  Given this, Node is perfect for applications where a near real-time experience is desired.

Getting started with a sample project

For the remainder of this blog post, I am going to show you how to get up to speed with Node.js coming from a PHP background.  The sample application that we are going to write is a simple backend service that will provide the location of every Walmart store.  I chose Walmart for this example because quite simply, it is the holy grail of all department stores.  If Walmart doesn’t have it, you don’t need it.

By the end of this blog post, you will see how quick and easy it is to create a REST based API using Node.js that is powered by the popular MongoDB database.  I chose this REST based example because creating a backend API has quickly became a common use case in most modern applications.

I had originally planned to create the same application in both PHP and Node.js to help ease the transition for you but in order to cover all of the different frameworks and ways of creating REST based services in PHP, it would warrant an entire book and simply can’t be covered in a single blog post.  I then thought about just using the Laravel framework as it is continuing to grow in popularity. However,  I would still only reach a quarter of the PHP developers.  Personally, my favorite framework is CodeIgniter but it is quickly losing ground and now only represents less than 8% of the PHP developer population.  Sitepoint recently published an article discussing this very thing and provides the following chart depicting the frameworks that show the most promise for 2014.

Given the vast differences in how to configure database connections and create REST services for each framework, I will assume that you know how to do this for your framework in PHP and instead will focus just on the Node.js code.

Creating our Node.js application

For the rest of this post, we are going to create the Walmart locator application using the LoopBack API framework from StrongLoop. As an added bonus, I will walk you through installing Node.js on OSX.  So grab your cup of coffee, sit back, relax, and let’s get to work.

Read more

Node.js API Tip: Offline Sync and Replication

Mobile technologies have radically changed our personal lives and are now doing the same in the workplace—perhaps not as rapidly as many of us would like!
Not every office looks like this, although at times we might feel this way. Many of us now have two or sometimes even three personal and company devices we wish were always in sync with realtime updates to email, schedules, storage, and even transactions. However, this is far from reality. Data replication and offline sync are not seamless across multi-vendor devices or disparate backends.

How does this affect the enterprise ?

The ability to work offline has emerged as a requirement for almost all data-driven enterprise mobile applications. This is especially true with relaxed BYOD policies plus enterprise field and sales enablement apps growing.
wilson 5w
However, a wireless app is only as good as the network. When disconnected from the network, a client app should have the capability to save the state of the transaction locally and synchronize with the server when it reconnects.

Until now, developers first had to figure out how to store a subset of the application’s data locally. Second, they had to implement a mechanism to keep the data synchronized on both the client and server.

Existing sync and replication techniques are limited to proprietary data sources, and are heavy and inflexible. Most synching is native in the implementation stack and also platform/device specific. Fine-grained controls on the behavior for common use cases like change detection and conflict resolution are also lacking.

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:


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.”

Qué hay de nuevo en Node.js v0.12: Balanceo de clusters con turno rotativo

Nota del editor
Bievenido a otra edición de lo que será una serie de unas siete u ocho publicaciones escritas por los contribuidores al núcleo de Node.js, Ben Noordhuis y Bert Belder. Abordando las nuevas opciones que se incluirán en la versión v0.12 de Node.js. En este primer artículo, Ben habla sobre el nuevo algoritmo de turno rotativo para clusters.

Recapitulación: Módulo de clusters de Node.js

En tiempos pasados, una limitación muy lamentada de Node.js era su modelo de un solo hilo de ejecución. Sin importar cuantos núcleos estuvieran disponibles en tu máquina, Node.js solo utilizaría uno (con la excepción de que algunas operaciones se descargan en el grupo de subprocesos. Para la mayoría de aplicaciones esto solo es una pizca en el tiempo del CPU, por lo cual esto realmente no ayuda con un mejor uso del poder disponible.)

Por eso es que Node.js v0.8 vió la adición del nuevo módulo integrado ‘cluster’. Este módulo permite configurar un proceso maestro que actúa como supervisor y uno o varios subprocesos que realizan el trabajo.

Uno de los objetivos era facilitar la creación de servidores de multi-procesos. En un mundo perfecto, deberías de poder tomar una aplicación con un solo proceso e iniciar cuantos procesos de trabajo consideres necesarios sin tener que cambiar una sola línea de código en tu aplicación.

Claro, nada es así de fácil, pero el módulo de clusters hace que sea sencillo para aplicaciones que tienen poco o ningún estado compartido, o que almacenan su estado compartido en un recurso externo como una base de datos o un servicio web. Convertir una aplicación como esa en una de clusters normalmente solo lleva algunas líneas de código:

La aplicación no necesita saber que está siendo ejecutada en un ambiente de clusters. Imagine que ese app() se ve así:

La (mayormente) magia blanca del módulo de clusters se asegura que el proceso del trabajador esté capaz de unirse al puerto y dirección solicitada, aún cuando otros trabajadores ya estén ahí escuchando. Más aun, asegura que las conexiones entrantes sean distribuidas de manera justa entre los trabajadores que escuchan…al menos en teoría.

En Node.js v0.8 y v0.10, el algoritmo para distribuir conexiones es sencillo. Cuando un proceso de trabajo llama a http.Server#listen() o net.Server#listen(), Node.js envía un mensaje al proceso maestro que le indica crear y enlazar un servidor de socket y compartir ese socket con el proceso de trabajo. Si ya existe un socket enlazado, el proceso maestro ignora los pasos de crear y enlazar y simplemente comparte el socket existente.

Eso significa que todos los procesos de trabajo escuchan al mismo socket. Cuando una nueva conexión llega, el sistema operativo inicia un proceso de trabajo. Ese proceso luego acepta la conexión y comienza a servir peticiones.

Hasta ahora todo bien. El sistema operativo recolecta una gran cantidad de métricas acerca de los procesos y por lo tanto debería estar en la mejor posición para decidir qué procesos iniciar.

En la práctica

Ahora llegamos a la parte donde la teoría se encuentra con la desordenada realidad porque lentamente se volvió claro que la idea del sistema operativo de “mejor” no está siempre alineada con la de un programador. En particular, se observó que en ocasiones – particularmente en Linux y Solaris – la mayoría de las conexiones llegaron a dos o tres procesos.

Luego despertar el proceso que bloqueó el pasado es la cosa más inteligente que hacer, ya que minimiza la posibilidad de tener que ejecutar un cambio de contexto. La premisa básica, que algunos procesos reciben un trato preferencial, aún mantiene sin embargo.)

Desde la perspectiva del sistema operativo, eso tiene algo de sentido: un cambio de contexto  (la suspensión de un proceso y a continuación, la reactivación de otro) es una operación bastante costosa. Si tienes n procesos que están esperando por el mismo socket, reactivar el proceso que se bloqueo por último es lo más inteligente ya que minimiza la posibilidad de tener que ejecutar un cambio de contexto. (Los organizadores son, claramente, bestias complejas y cambiantes; la explicación anterior es por necesidad un simple bosquejo de lo que realmente pasa. Sin embargo la premisa básica, de que algunos procesos reciban un trato preferencial, todavía queda en pie.)

No todas las aplicaciones son afectadas por esta peculiaridad – de hecho, la mayoría no – pero las que lo son, puede ver en realidad cargas muy desiguales/asimétricas.

Una vez que el problema de raíz fue identificado, se aplicaron medidas paliativas. Ninguna resultó muy satisfactoria. Dejar de escuchar al socket temporalmente para dar oportunidad de pelea a otros procesos para aceptar nuevas conexiones ayudó un poco, pero no lo suficiente. El número de conexiones que llegaron al grupo de los ‘elegidos’ bajó de 90% a 60-70% – mejor, pero todavía no ideal. No importa que tuviera un impacto dramático en el rendimiento de aplicaciones que trabajan con muchas conexiones de vida muy corta.

Más y más, era evidente que como la generación de números aleatorios, la distribución de conexiones entrantes es demasiado importante como para ser dejada al azar. En el transcurso de varias decisiones, se llegó a un consenso – nuestra última, mejor esperanza era simplemente botar el enfoque actual y cambiarlo por algo completamente distinto. Por eso, el módulo de clusters en Node.js v0.11.2 cambia a un enfoque de turno rotativo: nuevas conexiones son aceptadas por el proceso maestro, el cual entonces selecciona a un proceso de trabajo al que le entrega la conexión.

El algoritmo actual para seleccionar el proceso de trabajo no es muy sofisticado. Como el nombre lo sugiere, es turno rotativo – solo selecciona al siguiente proceso de trabajo disponible – pero las pruebas realizadas por usuarios y desarrolladores del núcleo, indican que funciona bien: las conexiones ahora son distribuidas de manera uniforme entre los procesos de trabajo. Convertir el proceso de selección en algo que sea configurable o conectable por el desarrollador es un cambio que se está considerando.
En el caso de que quieras regresar a la manera anterior de distribuir las conexiones, puedes cambiar cluster.schedulingPolicy en tu aplicación:

O configura la política de programación a través del ambiente con la variable NODE_CLUSTER_SCHED_POLICY:

En una sola línea que deja tu ambiente de consola intacto:

Una nota acerca de Windows

MS Windows es la única plataforma donde el antiguo método está todavía por defecto. Node.js en Windows usa IOCP para máximo desempeño. Aunque es muy bueno para la mayoría de cosas, hace que sea muy costoso enviar objetos de manillas (conexiones) a otros procesos. Es posible que eso se pueda ajustar en libuv pero no queda claro si es algo necesario o no: el puerto de Windows casi no ha sido afectado por problemas de balanceo en comparación con los puertos de Linux y Solaris.

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?

Getting Started with StrongLoop mBaaS on VMWare vCloud Air

Earlier this week at VMworld 2014 in San Francisco, VMware announced VMWare vCloud Air (previously, VMware vCloud Hybrid Service) “…working with leading mobility experts who provide Mobile Backend as a Service (mBaaS), world-class front-end mobile application development tools, mobile testing and analytics tools and mobile application development and integration services. These fit alongside mobile device and application management from AirWatch by VMware, to ensure IT and developers have everything they need to effectively build, securely connect, and comprehensively manage mobile services and apps through a hybrid cloud-based enterprise mobility ‘backbone’.”

Specifically, VMWare has partnered with StrongLoop to help make our mBaaS available on vCloud Air so that customers can use a hybrid approach to building out their mobile infrastructure, while allowing for a best of breed approach.

StrongLoop mBaaS highlights

For organizations looking to leverage vCloud Air for their mobile backbone, StrongLoop’s mBaaS offers many advantages:

  • On-premise – take control of your mBaaS and run it in your datacenter or on your own cloud infrastructure
  • Powered by LoopBack – the leading, open source API framework project built 100% in Node.js
  • Push – send alerts and popups to iOS and Android devices
  • Geopoint – compute position based on location, geo-spatial filters and sorting
  • Offline sync – isomorphic JavaScript front to back with conflict resolution and a variety of sync algorithms supported
  • Replication – client to server, server to client, app to app and database to database
  • Enterprise and social login – support for authentication through Facebook, Twitter, Google, GitHub and enterprise security services
  • Storage service – CRUD, upload and download files from AWS, Rackspace, OpenStack and Azure
  • User – Role based management with registration and token management

Here’s how to get started with vCloud Air and StrongLoop in four simple steps…

Step 1: Choose your operating system

Here are the basic options from the VMWare vCloud Air Marketplace

  • Ubuntu
  • Microsoft Windows Server
  • CentOS

Screen Shot 2014-08-25 at 12.19.46 PM

Complete catalog listing is here.

Step 2: Install Node.js

Download the appropriate Node installer based on your operating system.

Screen Shot 2014-08-25 at 12.19.22 PM

Downloads and installation instructions are here.

Step 3: Install StrongLoop

Installing StrongLoop is simple once you have Node installed. Simply execute:

$ sudo npm install -g strongloop

Step 4: Get Started

Now you are ready to start exploring features! Best place to start is the Get Started page and make sure to refer to the documentation for questions about how things work.

What’s next?