Esto no es algo nuevo para una persona que desarrolla en PHP. Desde hace años estamos acostumbradas a elegir entre Laravel, Symfony, Laminas, Lumen, CakePHP, Yii, etc. para facilitar el desarrollo y no tener que “pegarnos” con temas ya solucionados como el enrutado. Con Node.js la cosa no es diferente y tenemos en el mercado diferentes frameworks: Express, Hapi, Fastify, Koa, etc.

¿Cual elegir? Pues bueno, como siempre las soluciones mágicas no existen y ahí toca que cada uno evalúe sus requisitos y necesidades antes de “casarse” con una solución concreta. Hay muchas cosas a tener en cuenta: rendimiento, cantidad de documentación disponible, tamaño de la comunidad, etc. o incluso algunas bastante importantes si la decisión es para desarrollar una solución para una empresa, como por ejemplo la facilidad de encontrar personas que desarrollen con ese framework o el posible soporte profesional por parte de una empresa. En mi caso elegí Koa porque empieza a tener una comunidad creciente, se actualiza a menudo y ha sido creado por parte del equipo original de Express (que realmente es el más usado y sería otra buena opción para empezar).

Arrancando el esqueleto

A la hora de crear un proyecto nuevo en Node, descubrí que no es muy diferente a la filosofía de los proyectos PHP que hacen uso de Composer. Si en PHP tienes el fichero composer.json que es el que utilizas para gestionar dependencias, scripts de construcción, etc. en Node.JS tienes el fichero package.json.

Por lo tanto, lo primero que tenemos que hacer es inicializar el fichero package.json desde el cual gestionaremos todas las dependencias del proyecto. Comenzaremos entonces por crear un directorio para nuestro proyecto:

mkdir koa-test-api
cd koa-test-api

y a continuación ejecutamos

npm init -y

Esta instrucción crea un fichero package.json con el los valores básicos por defecto y que será el que usaremos como base para definir las dependencias del proyecto y definir los scripts de construcción.

{
  "name": "koa-test-api",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

A continuación instalamos las dependencias del proyecto, lo cual no difiere mucho de cómo venía haciéndolo en PHP con composer:

npm install koa koa-bodyparser koa-router koa-helmet

Con esta instrucción estamos instalando:

• koa: framework web ligero que nos facilitar la creación de un servidor http
• koa-bodyparser: middleware que ofrece utilidades para la gestión del cuerpo de las peticiones
• koa-router: middleware para la gestión de rutas
• koa-helmet: middleware para añadir cabeceras de seguridad en las respuestas

Instalando el lenguaje Typescript

Por defecto cuando arrancamos un proyecto de Node.js la opción por defecto es trabajar con Javascritp directamente. Para usar Typescript como lenguaje en nuestro proyecto necesitamos instalarlo. La instalación se hace con npm y tenemos dos opciones, instalarlo globalmente (como un comando más del sistema operativo) o como dependencia del proyecto en el que estás trabajando.

La opción más recomendable para instalar Typescript es instalarlo como dependencia de cada proyecto para así mantener la versión más indicada para cada uno de ellos, de forma que sea fácil trabajar en la misma máquina de desarrollo con distintas versiones del lenguaje.

Typescript se instala realmente como una dependencia sólo de la fase de desarrollo. Esto es así porque el código Typescript se va a transpilar (algunos prefieren llamarlo compilar) a código Javascript y es este último el que se ejecuta realmente en Node. Para instalarlo utilizamos el comando npm pasándole como opción --save-dev para que se instale como dependencia sólo de desarrollo:

npm install --save-dev typescript

Como Typescript es un lenguaje tipado, para aquellas librerías que no ofrecen los tipos directamente, hay que instalar dependencias adicionales.

npm install --save-dev @types/koa @types/koa-bodyparser @types/koa-helmet @types/koa-router

La configuración del lenguaje se almacena en un fichero tsconfig.json (que sería el equivalente al php.ini en PHP). Existen configuraciones recomendadas según la plataforma usadas y que se pueden extender (lo cual facilita el setup). Por ejemplo si estamos trabajando con Node 14 (última LTS al escribir esto) instalaríamos la siguiente dependencia de desarrollo:

npm install --save-dev @tsconfig/node14

Y en nuestro proyecto comenzaríamos el fichero tsconfig.json de esta forma:

{
  "extends": "@tsconfig/node14/tsconfig.json"
}

A continuación podemos añadir aquellas configuraciones que necesitemos para nuestro proyecto:

{
  "extends": "@tsconfig/node14/tsconfig.json",
  "compilerOptions": {
    "declaration": true,
    "sourceMap": true,
    "outDir": "dist"
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

El fichero tsconfig.json es muy importante porque es el que le dice al comando tsc cómo debe generar el código Javascript, es decir, con qué versión del lenguaje (ES3, ES5, ES6…), cómo hacer la carga de módulos y dependencias, qué destino va a tener el código (si se va a ejecutar en Node o bien en el navegador), etc.

Una vez instalado y configurado Typescript, necesitamos añadir la instrucción para poder “transpilar” el código Typescript a Javascript. Para ello añadimos una tarea en el package.json:

"scripts": {
    "build": "npx tsc"
}

Configurando un linter para ayudarnos a verificar el formato de nuestro código

Es buena práctica utilizar un linter para ayudarnos a cumplir un estándar en el formato de nuestro código. Hasta hace poco el linter recomendado para Typescript era tslint pero para desarrollos nuevos en la propia documentación de Typescript recomiendan usar en su lugar eslint.

Para ello primero instalamos el linter:

npm install --save-dev eslint @typescript-eslint/parser @typescript-eslint/eslint-plugin

Después de instalar el linter, tenemos que fijar las reglas de verificación. Éstas se configuran en el fichero .eslintrc

{
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2020,
          "sourceType": "module",
          "ecmaFeatures": {
            "jsx": true
        }
    },
    "extends": [
        "plugin:@typescript-eslint/recommended"
    ],
    "rules": {
    }
}

Añadiendo pretierr

Además del linter es recomendable tener alguna herramienta para formatear nuestro código y dejarlo con el estilo con el que más nos sintamos cómodos, o bien, para dejar el código según la guía de estilo de nuestra empresa.

Uno de los recomendados es prettier que se integra bien con eslint. El primer paso sería, como con cualquier otra dependencia de desarrollo, instalarlo. Para instalar prettier junto con el soporte para integrarse con nuestro linter ejecutaremos:

npm install --save-dev prettier eslint-config-prettier eslint-plugin-prettier

Como otras tantas herramientas de desarrollo, prettier usa un fichero de configuración llamado .prettierrc:

{
  "semi": true,
  "trailingComma": "all",
  "singleQuote": true,
  "printWidth": 120,
  "tabWidth": 2
}

Para integrarlo con eslint modificaremos nuestro fichero .eslintrc para incluir las reglas recomendadas:

{
    "parser": "@typescript-eslint/parser",
    "parserOptions": {
        "ecmaVersion": 2020,
          "sourceType": "module",
          "ecmaFeatures": {
            "jsx": true
        }
    },
    "extends": [
        "plugin:@typescript-eslint/recommended",
        "prettier",
        "plugin:prettier/recommended"
    ],
    "rules": {
    }
}

A continuación es recomendable añadir un script nuevo en nuestro package.json para poder ejecutar el linter a mano cuando lo necesitemos:

"scripts": {
    "build": "npx tsc",
    "lint": "npx eslint 'src/**/*.{js,ts,tsx}' --quiet --fix"
}

Empezando a escribir código

Vale, ya tenemos el entorno base para poder compilar Typescript ahora podemos empezar a escribir algo de código. Vamos a empezar por (como no podía ser de otra manera) con un pequeño “Hola Mundo” en formato API JSON, de forma que cuando llamemos al raíz del servidor nos devuelva el siguiente JSON:

{"hello":"Koa"}

Para necesitamos:

• Arrancar Koa
• Definir la ruta raíz
• Hacer el código necesario para devolver el JSON que queremos
• Arrancar el servidor

Como este es un ejemplo muy sencillo y básico, vamos a meter todo el código (que tampoco es demasiado) en un único fichero src/app.ts que va a tener el siguiente contenido:

import Koa from 'koa';
import Router from 'koa-router';
import BodyParser from 'koa-bodyparser';

const application = new Koa();
const router = new Router();

router.get('/', async (ctx, next) => {
  ctx.body = { hello: 'Koa' };

  await next();
});

application.use(router.routes()).use(router.allowedMethods());
application.use(BodyParser());

application.listen(3000);

Aunque vengamos de otro lenguaje de programación, como en mi caso PHP, la estructura de este código nos resultará familiar y fácilmente entendible, aunque, vamos a analizarlo un poco para entenderlo.

Las primeras 3 líneas son la importación de las dependencias, es decir decir qué recursos de las librerías necesitamos para nuestro código:

import Koa from 'koa';
import Router from 'koa-router';
import BodyParser from 'koa-bodyparser';

Para las personas que desarrollamos PHP en las versiones más actuales nos resultará fácil identificar estos import con los use de PHP como por ejemplo:

<?php

use Slim\App;
use Slim\Middleware\ErrorMiddleware;

A continuación tenemos la creación de los objetos que necesitamos:

const application = new Koa();
const router = new Router();

En este caso tenemos creamos dos objetos application y router. El primero es el framework en sí mismo y el segundo el “enrutador” que nos va a facilitar definir las rutas que nuestro API va a ofrecer. Éstas se definen de la siguiente forma:

router.get('/', async (ctx, next) => {
  ctx.body = { hello: 'Koa' };

  await next();
});

Aquí le estamos diciendo al enrutador que cuando se reciba una petición HTTP a la ruta raíz se derive la ejecución al callback. Ésta función callback lo único que hace es cambiar el valor del cuerpo de la respuesta al objeto que nos interesa.

¿Y como le decimos a Koa que existen esas rutas y que lo que tiene que devolver es un JSON?. Pues bien, Koa se basa en la utilización de middlewares para delegar ciertas funcionalidades y para ello sólo hay que decirle a Koa que los use:

application.use(router.routes()).use(router.allowedMethods());
application.use(BodyParser());

En la primera línea estamos inyectando en Koa el middleware de enrutado y en la segunda uno que nos permite manejar de forma fácil la salida en los formatos más estándar. En este caso la función de BodyParser() es la que permite pasar a la propiedad ctx.body un objeto y que en la salida tengamos un JSON bien formado y con sus cabeceras.

Ya, por último, nos queda arrancar el servidor. Si habéis leído mi entrada anterior y venís del mundo PHP recordaréis que no necesitamos un servidor web como Apache o Nginx para ejecutar nuestro código en Node, si no que tanto Node como los framework como Koa son capaces de manejar tráfico HTTP por ellos mismos. Para eso tenemos la última línea de nuestro código

application.listen(3000);

Aquí le estamos diciendo que se ponga a escuchar en el puerto TCP 3000, con lo que ya estamos en disposición de ir a la consola y “transpilar” nuestro código. Para ello ejecutamos:

npm run build

Con lo que veremos algo similar a esto en la salida

javiercaride@beast:~/workspace/koa-test-api$ npm run build

> koa-test-api@1.0.0 build /home/javiercaride/workspace/koa-test-api
> npx tsc

javiercaride@beast:~/workspace/koa-test-api$ 

Bien, ya estamos en disposición de ejecutar nuestro código, pero antes debemos añadir en el package.json una tarea más para facilitar el arranque del servidor, concretamente la línea start del objeto scripts:

  "scripts": {
    "build": "npx tsc",
    "lint": "npx eslint 'src/**/*.{js,ts,tsx}' --quiet --fix",
    "start": "node dist/app.js"
  }

Si volvemos a la consola y ejecutamos npm start veremos que se ejecuta algo pero que no devuelve el control al terminal:

javiercaride@beast:~/workspace/koa-test-api$ npm start

> koa-test-api@1.0.0 start /home/javiercaride/workspace/koa-test-api
> node dist/app.js

Esto significa que nuestro primer programa en Typescript con Koa se ha puesto a escuchar en el puerto 3000. Vamos a probarlo ejecutando en otra consola el siguiente curl:

curl -i -X GET 'http://localhost:3000/'

Y como por arte de magia veremos lo siguiente:

HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Content-Length: 15
Date: Sat, 19 Jun 2021 15:32:48 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"hello":"Koa"}

Como podéis comprobar nuestras 17 líneas de código son capaces de responder una petición HTTP GET, devolver un objeto JSON y las cabeceras correctas para interpretar la respuesta.

Si hiciésemos una solicitud con método POST, por ejemplo:

curl -i -X POST \
   -H "Content-Type:application/json" \
   -d \
'{}' \
 'http://localhost:3000/'

Veríamos como nos respondería con un código de respuesta 405 (Method not allowed):

HTTP/1.1 405 Method Not Allowed
Allow: HEAD, GET
Content-Type: text/plain; charset=utf-8
Content-Length: 18
Date: Sat, 19 Jun 2021 15:36:36 GMT
Connection: keep-alive
Keep-Alive: timeout=5

HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
Content-Length: 9
Date: Sat, 19 Jun 2021 15:38:32 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Not Found

Y si hiciésemos la petición por GET, pero a una ruta diferente:

curl -i -X GET 'http://localhost:3000/user'

Obtendríamos un 404 (Not Found):

HTTP/1.1 404 Not Found
Content-Type: text/plain; charset=utf-8
Content-Length: 9
Date: Sat, 19 Jun 2021 15:38:32 GMT
Connection: keep-alive
Keep-Alive: timeout=5

Not Found

Conclusión

Aunque los comandos, nombre de los ficheros de configuración, frameworks, etc. son completamente distintos, los conceptos básicos de montar un esqueleto para un API en NodeJS con Typescript y Koa no son muy diferentes a hacerlo en PHP con cualquier framework ligero, lo cual hace que el proceso de cambiar de stack tecnológico no tenga una curva de aprendizaje demasiado difícil.

Próximos pasos

Ahora que tengo un esqueleto muy básico de un API (pero muy muy básico) los siguientes puntos que quiero abordar son:

• Aprender antes de nada como desarrollar tests, para lo cual me adentraré en el framework Mocha
• Establecer una estructura de proyecto completamente agnóstica de Koa de forma que el código con la lógica de negocio pueda reutilizarse con otro framework (por ejemplo Express)

Los más avanzados explorarán ya Nginx con PHP-FPM pero, en esencia, viene a ser prácticamente lo mismo: un servidor web que se encarga de (simplificándolo mucho) la comunicación HTTP y entregar recursos necesarios al navegador web, y “algo” (un módulo del servidor o un demonio) que se encarga de ejecutar PHP y devolver la salida correspondiente a través del servidor.

Casi todas las distribuciones de Linux cuentan con los paquetes necesarios para empezar y hay muy buenos tutoriales sobre como hacer el setup. Incluso hay proyectos como XAMPP que facilitan mucho la vida para montar entornos de desarrollo mediante la distribución de un paquete que contiene servidor web, PHP, y base de datos.

En Node.js la cosa cambia un poco. Los que venimos de PHP podemos estar tentados a buscar un módulo para ejecutarlo “embebido” en algún servidor web (Nginx o Apache), pero no.

Para ejecutar Node.js tan sólo necesitamos ir a su página web, descargar la versión acorde a nuestro sistema operativo, instalarla y ya dispondremos de un nuevo comando node en nuestra línea de comandos (bueno realmente se nos instalan muchos más, pero en este momento no nos importa):

javiercaride@beast:$ node
Welcome to Node.js v14.15.4.
Type ".help" for more information.
> 

Hay que tener claro que Node.js es un entorno en tiempo de ejecución que permite la ejecución de código Javascript fuera del navegador y que está pensado (aunque no en exclusiva) para la capa del servidor. Se construyó sobre el motor V8 de Google y además de la ejecución del Javascript ofrece un API orientada a facilitar la construcción de aplicaciones en Javascript capaces de gestionar conexiones HTTP, Web Sockets, eventos asíncronos, etc.

Es por ello que Node.js no necesita de un servidor web para funcionar ya que él mismo puede gestionar las conexiones HTTP con el navegador cliente. De hecho el “hola mundo” más básico que podemos tener con node es el siguiente:

const http = require('http');

const hostname = '127.0.0.1';
const port = 8080;

const server = http.createServer((req, res) => {
  res.statusCode = 200;
  res.setHeader('Content-Type', 'text/plain');
  res.end('Hola mundo');
});

server.listen(port, hostname, () => {
  console.log(`Servidor ejecutándose en http://${hostname}:${port}/`);
});

En este código lo que estamos haciendo es levantar un servidor HTTP en el puerto 8080 y que cada vez que llegue una conexión a ese puerto se responda con el texto Hola mundo. Si guardamos este trozo de código en un fichero hola_mundo.js y ejecutamos:

$ node hola-mundo.js 
Servidor ejecutándose en http://127.0.0.1:8080/

Veremos que en la consola obtenemos el mensaje Servidor ejecutándose en http://127.0.0.1:8080/ y si vamos al navegador veremos que node está respondiendo como si fuese un Apache o un Nginx:

¿Qué opción es la mejor para instalar Node.js?

Antes dije que para usar Node sólo tenemos que instalarlo y ya, pero ese sólo puede abrumarnos en un principio porque en la página de descargas de Node.js podemos ver que las opciones son numerosas:

• Binarios: (tanto instaladores oficiales para Windows como compilados para macOS / Linux)
• Contenedores docker
• Gestores de paquetes
• Código fuente para compilarlo uno mismo

Este gran número de opciones pueden confundirnos en un principio y más porque se nos ofrece 2 versiones diferentes de Node.js: la más reciente y la LTS

Pues aquí no hay una solución infalible, va a depender mucho del sistema operativo que utilices y del uso que vayas a hacer de Node.js.

Si sólo vas a cacharrear un poco para probar seguramente con bajar el binario correspondiente a tu sistema operativo sea suficiente. O, en el caso de las distribuciones de linux, sea mucho más fácil instalar el paquete que viene oficialmente en la distribución, aunque has de tener en cuenta que con este método normalmente no vas a tener la última versión.

En cuanto llevas cierto tiempo con Node, te acabas dando cuenta de que es una comunidad muy activa y que el entorno evoluciona muy rápidamente, con lo que hay versiones nuevas muy a menudo y éstas traen, a veces, cambios que no son compatibles hacia atrás o bien las librerías que usas no funcionan bien en la última versión disponible.

En esos momentos el tener instalado Node como binario disponible de forma global en el sistema operativo o mediante el paquete de tu distribución Linux hace que no sea cómodo cambiar de versión y puede dificultar el día a día, sobre todo si lo usas en proyectos profesionales.

Es aquí donde yo veo una gran ventaja utilizar un gestor de paquetes que te permita instalar distintas versiones de node de forma local a tu usuario y cambiar entre una u otra de forma muy fácil. Esto te permite probar versiones nuevas con poco riesgo y sin pasarte horas reconfigurando tu entorno de desarrollo.

De todos los que he probado el que más me ha gustado a mi es nvm. Y reitero que es la opción que más me ha gustado a mi y que mejor se adapta al uso que hago y al sistema operativo que utilizo (Ubuntu LTS). Mi recomendación es que probéis distintas opciones y adoptéis la que mejor se os adapte a vosotros.

El gestor nvm es un script de bash que se instala muy fácilmente ejecutando el script sh que su autor provee:

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.37.2/install.sh | bash

Tras la instalación dispondréis en vuestra línea de comandos del comando nvm que os permitirá instalar distintas versiones de Node.js (y sus herramientas) y, lo más potente, cambiar de una a otra de forma sencilla.

Por ejemplo si queremos instalar la última versión LTS sólo tendríamos que ejecutar:

nvm install --lts

Si además de la LTS queremos instalar una versión concreta porque tenemos un proyecto que la necesita sólo tendremos que indicarlo:

nvm install 15.8.0

y para usarla se lo decimos a nvm:

nvm use 15.8.0

Si ahora le preguntamos al sistema operativo whereis node veremos que obtendremos que apunta a la instalación local que nos ha dejado nvm y a la versión que le hemos pedido:

$ whereis node
node: /home/javiercaride/.nvm/versions/node/v15.8.0/bin/node

Las opciones de este gestor de paquetes node son amplias y están bien documentadas en su página de Github

Recuerdo que me llamó mucho la atención la facilidad de usarlo y como con unos pocos ficheros podías hacer una web dinámica. Eran los años en los que la burbuja de las .com estaba engordando y todo el mundo quería “tener” eso que empezaba a llamarse web 2.0.

Hasta aquel entonces lo poco que había hecho de web dinámica era con C, compilando unos rudimentarios cgi. Descubrir PHP por aquel entonces me supuso un incremento en la velocidad de desarrollo bestial. Desde entonces ha sido mi lenguaje de programación favorito y en el que he desarrollado prácticamente el 90% de mi código. Aunque he tenido épocas y proyectos profesionales en los que he trabajado en otros lenguajes como Java, PHP me ha acompañado en todos los proyectos de mi carrera profesional.

El lenguaje ha ido evolucionando y desde aquel rudimentario 3.0 el lenguaje se ha ido haciendo cada vez más y más profesional, y a pesar de haber leído multitud de veces artículos titulados “La muerte de PHP” (y haber salido al mercado serios “competidores” como Ruby on Rails y NodeJS) sigue siendo uno de los más utilizados para desarrollo web, sobre todo debido a su amplia comunidad de desarrolladores y a que tiene una curva de aprendizaje muy asequible.

Precisamente de todos sus “competidores” puede ser que NodeJS haya sido el que más terreno le ha ganado y sobre todo al stack tecnológico al que más desarrolladores de PHP se hayan “convertido”.

Yo reconozco que desde su aparición me subí al carro de los memes que empezaron a circular entre los grupos de desarrollo en los que la gente se burlaba sobre la idea de ejecutar Javascript en el servidor tachándolo casi de juguete infantil. Y durante muchos años lo he obviado, principalmente porque con PHP estaba en una zona de confort muy cómoda: todo lo que me había ido proponiendo desarrollar lo acababa haciendo en PHP sin muchas o pocas dificultades.

Pero el tiempo ha ido pasando, NodeJS ha ido madurando también y generando una legión de adeptos que han gestado una comunidad muy importante de desarrolladores y un “ecosistema” de aplicaciones, bibliotecas y herramientas que lo han convertido en una opción seria. También le ha ayudado mucho el empujón que ha recibido tras popularizarse las arquitecturas basadas en microservicios (donde NodeJS puede usarse para hacer APIs muy ligeras y rápidas) y las orientadas a eventos (donde la asincronía nativa de NodeJS juega un punto a favor).

También yo he ido madurando como profesional y creo que ha llegado el momento de dejar de odiar este stack tecnológico para darle una oportunidad. Sobre todo quiero dejar de odiarlo de forma totalmente irracional y sin haberlo probado. Creo que para rechazar una tecnología o stack tecnológico primero se debe probar, y experimentar por uno mismo sus pros y contras y luego decidir si se desea profundizar en su conocimiento. Además, considero que ya es hora de salir de mi zona de confort y dejar de utilizar PHP “para todo”.

Así que me he puesto manos a la obra y he empezado a montar un pequeño mini-proyecto desde cero usando NodeJS con Typescript y ExpressJS para poder entender las entrañas de este stack. La razón de usar Typescript es por una parte profesional (forma parte del stack tecnológico de STAY, compañía en la que trabajo ahora) y por otra parte porque siempre me han gustado más los lenguajes fuertemente tipados (de hecho soy de los programadores que están encantados con el giro que está dando PHP desde la versión 7.0).

En los próximos artículos iré describiendo como está siendo la experiencia desde el punto de vista de un programador anclado muchos años en el viejo PHP.

Han pasado ya unos 7 años desde que desistí de ese proyecto, pero ahora (más viejo y por lo tanto más “sabio”) vuelvo a emprender la aventura de abrir un site personal donde contaros de nuevo batallitas sobre desarrollo de software y curiosidades tecnológicas. Pero esta vez emprendo el proyecto con el simple objetivo de contar cosas que puedan ser útiles a alguien. Atrás quedaron los sueños por llegar en algún momento en ser famoso dentro del panorama blogger tecnológico español.

Este nuevo proyecto empieza de una forma más humilde, aprovechando la facilidad de mantener un blog estático con Jekill y sobre todo sin ningún objetivo de ganar fama o convertirse en un referente.

Espero entreteneros y que si alguien acaba leyendo mis posts le sirvan de algo.