Construyendo una app modular en node.js

Hace años que trabajo con node.js, llegando a convertirse en mi principal entorno en backend e incluso un poco en frontend con nw.js, y aun así, cada proyecto nuevo que inicio, es una odisea para encontrar la mejor estructura en la que tenga máxima flexibilidad sin crear un sistema de carpetas demasiado complejo.

Yo cada vez que inicio un proyecto nuevo ¡party hard!

No os podéis imaginar la de veces que he reestructurado mi código, buscando siempre la mejor forma.

Ahora me doy cuenta que la respuesta a una pregunta tan compleja es muy sencilla. La respuesta es que no hay mejor forma, sino estructuras que funcionan mejor que otras, dependiendo del tipo de aplicación que quieras hacer.

Lo que sí queda claro es que, hoy por hoy, un sistema modular es probablemente la mejor forma de desarrollar una aplicación, ya que es difícil saber cómo va a crecer. Por ello voy a explicar cómo crear una app modular en node.js, y si eso, dar una estructura base para empezar.

¿Por qué node.js? Porque node.js es uno de los entornos más flexibles, con más librerías open source que me han echado a la cara.

¿Por qué modular? Porque da muchas ventajas, entre las más notables:

• Permite reutilizar código entre los diferentes módulos que forman la aplicación, incluso pudiendo reutilizar módulos entre servidor y cliente.
• Cuando la aplicación tiene que crecer o cambiar, ayuda a minimizar la cantidad de código que hay que reescribir, incluso no siendo necesario reescribir nada si se plantea bien desde un principio.
• Permite comprender el código mucho más fácilmente, al tener poco código en cada archivo en vez de miles de líneas.

Empecemos con el lío.

Para empezar, necesitamos tener un binario de node.js. Es tan sencillo como hacer click aquí para descargar un ejecutable standalone, sin instalaciones. Lo guardamos en una carpeta, abrimos la consola de comandos y vamos a crear nuestro primer script, para probar que todo está correcto. Lo vamos a llamar main.js, mismo, y lo guardamos junto a nuestro binario de node.js:

Ahora vamos a meter en el archivo esto:

console.log("Hola desde node.js :P");

Y lo ejecutamos escribiendo en la consola de comandos node main.js, y se debería ver el resultado:

Perfecto. Ahora creamos la carpeta lib y ya estamos listos. Vamos a por los módulos.

Node.js funciona mediante módulos. Hasta el mismo script inicial se ejecuta como tal. Incluso las funciones internas de node.js (para acceder al sistema de archivos, por ejemplo) son módulos.

Yaaay... ¿?

Tranquila April, eso no es malo. Un módulo es algo diferente a los includes de C a los que más de uno está acostumbrado. Un módulo es un componente aislado del resto de la aplicación, es decir, cuando se incluye un módulo, este se ejecuta aparte, sin mezclar su código con el código del módulo que lo carga. Puedes tener 3 módulos diferentes con código que declara los mismos nombres de variables sin problemas. Cada uno tendrá acceso a su variable "local".

Como supongo que te estarás preguntando ya, si los códigos no se mezclan y no tienen acceso a las variables del resto de módulos ¿cómo interactúan entre ellos?

Cada módulo debe exportar las variables que desee que sean accesibles desde otros módulos, utilizando module.exports.

Vamos a empezar por lo fácil. Creamos un simple script, tal que así:

var saludo = "Hola";

function saludar(nombre) {
    console.log(saludo + " " + nombre);
}

module.exports = saludar;

Esto ya es un módulo. Lo voy a guardar como saludo.js dentro de la carpeta lib.

Si quisiéramos saludar a alguien, tendríamos que cargar el módulo con require(), lo cual devolverá el contenido de module.exports, el cual contiene una referencia a la función saludar(), así que dentro de nuestro main.js simplemente tendríamos que hacer lo siguiente:

var saludar = require("./lib/saludo");

saludar("Pepe");
saludar("Juan Doe");

E ya. Con require() hemos cargado nuestro otro módulo, el cual exporta una referencia de una función, pero no exporta la variable saludo, por lo tanto si hiciéramos

console.log(saludo);

devolvería error, ya que no forma parte de este contexto.

Vamos a complicar más las cosas. Vamos a crear dos módulos, juan.js y pepe.js, los cuales cargarán nuestro módulo saludo.js, tal que así:

/* lib/juan.js */
var saludar = require("./saludo");

function saludarJuan() {
    return saludar("juan");
}

module.exports = saludarJuan;

/* lib/pepe.js */
var saludar = require("./saludo");

function saludarPepe() {
    return saludar("pepe");
}

module.exports = saludarPepe;

Y ahora vamos a jugar con ellos:

var juan = require("./lib/juan");
var pepe = require("./lib/pepe");

console.log(juan());
console.log(pepe());

En este código estamos cargando los módulos juan.js y pepe.js, y estos cargan el módulo saludo.js. Esto no quiere decir que el código de saludo.js es ejecutado 2 veces, ya que node.js es lo suficiente espabilado para cachear el módulo la primera vez que lo ejecuta y devolver esta caché las siguientes veces que se hace require().

Vamos, esos cinco April, que node masmola

Y con esto ya hemos sentado las bases de una aplicación modular en node.js. Como veis, si quisiéramos cambiar la forma de funcionar del saludo, tan sólo tendríamos que modificar saludo.js sin preocuparnos de nada más que exportar la función que queremos que se llame. Fácil, cómodo y JavaScript :P ¿Qué más se puede pedir?

Más adelante hablaré de una aplicación ¿supermodular? que estoy preparando. Con supermodular me refiero a una aplicación modular que es capaz de cargar módulos en caliente, sin necesidad de reiniciar el proceso principal y sin perder las referencias a los módulos antiguos mientras estos hagan falta. Es la magia de node.js.

Leer más

Script Blogger: Ayudas para las imágenes en el editor

Después de crear mi primer post, enseguida empecé a sufrir un par de problemas que tiene el editor de Blogger. Uno de ellos es una función añadida, pero que resulta bastante molesta, y la otra es una función que falta añadir.

La función molesta es que cuando añades una imagen, Blogger automáticamente crea un enlace clickable que apunta a la misma. Está claro que está bien poder hacer click en una imagen y verla a pantalla completa, pero dos cosillas; primero, que esa es una opción que el usuario debería elegir cuando añade una imagen en vez de estar de serie, y segundo, que no hay peor forma de ver una imagen a pantalla completa que simplemente abrir el enlace en el navegador. Con lo famosa que es la plataforma Blogger, si van a forzar esa situación, ya podrían haberse currado un visualizador de fotos, en vez de esa cutrez.

Se puede solucionar simplemente haciendo click en la pestaña HTML y modificando el código para borrar el link, pero, de nuevo, no es una forma bonita de hacer las cosas.

Cawen la leche, Blogger...

Como no puede ser de otra forma, ya estoy solucionando a golpe de script esas cosillas que no me gustan. He creado un script de Greasemonkey (Tampermonkey en Chrome) que realiza 2 funciones:

• Eliminar los enlaces que se crean automáticamente cuando añades una imagen.
• Poder añadir y y quitar clases de estilos CSS con un sólo click.

Yo en el mismo momento de crear este script

Con este script escribir entradas se hace más cómodo. Simplemente tengo que definir las clases que quiera en el header de la plantilla y, después de configurar el script, puedo aplicarlas a mis imágenes con un simple click.

¿Cómo instalar y configurar el script?

Para instalar el script hay que tener la extensión Tampermonkey (Chrome) o Greasemonkey (Firefox) instalada, entrar en uno de los siguientes enlaces: Greasyfork o OpenuserJS y hacer click en el botón Instalar este script o install, dependiendo de la página.

Después de haber instalado el script, hay que ir al panel de control de la extensión que hayas instalado, abrir el script y buscar la línea que empieza por var config = {

La configuración de serie viene con removeAnchor activado (true para activar, false para desactivar) y con 2 clases configuradas, gif e img.

Si activas removeAnchor, automáticamente va a eliminar los molestos enlaces clickables cada vez que añades una nueva imagen.

Viendo las dos clases se puede ver que tienen un color configurado, red y blue en este caso. Es es color que se mostrará en el editor para, visualmente, saber qué clase has colocado a una imagen. También están configuradas como unique (de nuevo true para activar y false para desactivar), lo que indica que sólo se permite tener una de esas dos clases activa a la vez. Si desactivas unique, entonces puedes colocar las dos clases a una misma imagen.

Después de configurar el script, nos vamos al editor de Blogger, añadimos una nueva imagen y hacemos click sobre ella. En el menú que se muestra bajo la imagen al hacer click, se podrá observar a la izquierda unos botones con los nombres de las clases configuradas, SET img y SET gif:

Y que al hacer click en uno de ellos, se enmarca la imagen con el color que hemos configurado y cambia el texto a REMOVE:

Simplemente con un click ya hemos cambiado el atributo class de nuestro <img>. Ahora sólo falta ir a la plantilla, editar el HTML y añadir en el header el código CSS que más nos guste. En mi caso:

Este CSS simplemente redondea el borde. Aunque el código sea el mismo para las dos clases, los diferencio porque así puedo ejecutar la librería Gifffer bajo todos los elementos que contengan la clase gif. Ya hablaré en otro post sobre ella.

Se acabó.

¿Eh? ¿Qué? ¿Ya? Me había dormido...

Leer más

Nuevo blog, nuevo lenguaje: TypeScript

¿Qué mejor forma de iniciar un blog que hablando del lenguaje que acabo de estrenar? Typescript, un lenguaje de programación de código libre desarrollado por Microsoft.

Sí, Microsoft y código libre en la misma frase.

Mi careto cuando ví esta noticia

Para muchos de la "old school" es algo extraño, pero realmente Microsoft lleva un tiempo haciendo las cosas así, y es de agradecer. No sé si estoy cambiando mi forma de pensar con respecto a ellos, pero, en los últimos meses, no es la primera vez que me beneficio de un producto desarrollado por Microsoft sin que me obliguen indirectamente a ello (Véase: Windows Monopolio).

¿Qué es Typescript? Typescript es Javascript con anabolizantes. Añade a Javascript todo lo que más de una vez has echado de menos cuando te has encontrado con un undefined en un sitio donde no debería estar, pero sin perder la "magia" del mismo.

Typescript añade clases, tipos, control de argumentos, etc. Vamos, da la sensación de estar programando en .NET (Javascript.net?), pero mantiene la versatilidad de Javascript que tanto nos gusta.

Pero ¿Qué entornos soportan Typescript? Muy sencillo, cualquier lenguaje que acepte Javascript. Typescript compila en Javascript sin problemas. Es más, se diseñó principalmente bajo esa idea. La mayoría de IDEs (Visual Studio Code por aquí), tienen integrado el compilador a Javascript y, con tan sólo una combinación de teclas, convierte tus archivos .ts a .js, dejándolo todo listo para lanzar tu proyecto en Node, tu navegador preferido (Chrome por aquí, como era de esperar) o incluso Windows CScript.

Y todo ésto con la comodidad de poder repasar el código en GitHub, con todas las ventajas que ésto supone.

¿Qué más decir? Por mi parte, nada más. A mí ya me han comprado.

Más adelante hablaré más exhaustivamente sobre Typescript. Lo dejo aquí por ahora.

Leer más