No, no estaba muerto, tampoco de parranda, solo no sabía que hacer por acá. Venía pensando en que quiero poner más contenido acá, más cosas para aprender y enseñar, pero últimamente me queda cada vez más difícil o simplemente me complico (distraigo) más en ejecutar una idea para postear.

Pero en definitiva lo que si quiero es hablar de lo que pienso, contarles las cosas que llevo en mi cabeza y ojalá aprendamos un poquito de tecnología, así que les voy a contar cuáles son las últimas noticias y mis opiniones al respecto.

• Nvidia (la empresa de tarjetas de video), junto con Intel, sacaron los procesadores NVIDIA RTX Spark™ Superchip: estos "procesadores" son una combinación de CPU y GPU en arquitectura ARM. No es algo estrictamente nuevo, pero a según, tienen rendimiento de una RTX 5070 en gráficos y procesadores de hasta 20 núcleos de alta "eficiencia". Esperar a que salgan a la venta a ver, porque por ahora no han anunciado precios o cómo se adquieren y no me puedo dar una opinión al respecto.
• Hace tiempo (semanas atrás) salió una noticia acerca de como un agente de IA borró la base de datos y los respaldos de toda una empresa en 9 segundos: en internet, YouTube y Reddit puedes encontrar varias noticias al respecto, pero en general, sólo quería decir que me causó algo de gracia, pero no me refiero al hecho de la desgracia ajena o burlarme de esta empresa, sino de cómo se "impulsa" el uso de agentes sin control o noción porque los jefes quieren ver más "producción" más rápido. Y si tan sólo uno se sentara a planificar un rato, estas situaciones se pueden prevenir fácilmente (o a lo mejor no había forma de prevenirlo porque el usuario ni sabía del poder o lo que este agente estaba haciendo).
• Google había anunciado TurboQuant AI, un algoritmo que reduce 6 veces el uso de memoria para los modelos de IA. Esta tecnología se esperaba, o aún se espera, que reduzca los precios de las memorias RAM (y SSDs) debido a que muchas compañías estaban desistiendo de adquirirlas para los data centers. Han pasado 2 meses y aún no ha regresado a la normalidad, pero yo sigo cruzando mis dedos y esperando que todo sea barato de nuevo 😄!

En general, todas las noticias rondan la IA, incluyendo la de NVIDIA, ya que estos "súper chips" se ofrecen como soluciones de cómputo local para poner en ejecución cualquiera de estos modelos mega gigantes de IA... Y más IA... Y un poco más de inteligencia, pero que sea de la artificial... Y así están todas las noticias.

Entonces, trataré de ponerme más al día, sacar mensajes o enseñanzas para todos acá, conclusiones, cosas de mi trabajo o del simple día a día.

Pero si quieres escuchar o leer algo en especial, ¡sólo dime y con mucho gusto te ayudo!

Si queremos saber o buscamos en Google cuál es la diferencia entre React Native y React.js, encontraremos un montón de páginas y posts que establecen la diferencia a nivel técnico, o dicho de otra manera, las detalles, los protocolos y otras micro diferencias, sin hablar a grandes rasgos.

Para un lector no técnico, estos posts no indican absolutamente nada, sólo mucho texto acerca de cosas HTML, CSS, renderizado, componentes, integraciones, natividad y otras "buzz words" que no dicen nada.

Entonces quiero colocar y dejar acá una de las principales diferencias que no necesariamente conseguimos en todos los posts, para específicamente dejarle saber a todos esos "tech head hunters" que se me han acercado con alguna oferta en React en mente:

React.js es una tecnología para construir aplicativos web (frontend para páginas web) y React Native es una tecnología para construir aplicativos para dispositivos móviles agnóstio al sistema operativo.

Entonces, señor reclutador, la próxima vez que te acerques diciendo "tengo una oferta increíble para un desarrollador frontend como tú que sepa React para crear páginas web" no me envías una ¡m@ldit@ "prueba"! para "desarrollar" o contestar preguntas acerca de React Native.

¡No!, por favor no lo hagas, no lo intentes, no lo fuerces con palabras tipo "pero es casi lo mismo, ¿no?, entonces podrías intentarlo, ¿no?" o llenes un p#t0 formulario indicando "el desarrollador mintió acerca de su experiencia" porque ambos sabemos que no es así, es un error tuyo como "reclutador tech" al no saber las diferencias.

TLDR; Así como tu aplicativo o solución tiene versiones, la base de datos también debe tener versiones, las cuales pueden actualizarse a una versión mayor a través de "upgrades" o ser revertidas a versiones anteriores con "downgrades". Esto asegura que tu aplicativo pueda ser usado en diferentes etapas de su evolución de acuerdo a los requerimientos con integraciones o actualizaciones del cliente. En este post hablamos sobre qué son "migraciones" de una base de datos y construimos 3 ejemplos para aplicativos en Node.js con Sequelize, Node.js con TypeORM y Flask con SQLAlchemy y Alembic.

Enlaces a documentaciones oficiales:

• Documentación de Sequelize
• Documentación de TypeORM
• Documentación de Alembic
• Documentación de Flask-Migrate

También te dejo este enlace donde se encuentran los ejemplos de es Post en GitHub: Migraciones con Node.js y Python.

Entonces, ¿Qué son las "migraciones" en una base de datos?

De manera muy corta y sencilla, las migraciones en una base de datos es el versionamiento del esquema, o de las tablas o de la relación entre entidades (ERD -Entity Relationship Diagram-), de acuerdo con la evolución de tu aplicativo.

Ejemplo de un aplicativo web de correspondencia

En un ejemplo práctico: imagina que has desarrollado un aplicativo web para el seguimiento de envío de correspondencia física, como sobres y paquetes, que consta de un frontend, un backend y una base de datos.

Este aplicativo tiene varias funciones y características, sin embargo, vamos a enfocarnos que un usuario final tiene la posibilidad de ver el próximo envío a recibir en una interfaz que le muestra desde donde viene, a donde se va a entregar y qué día será entregando, incluyendo una aproximación en la parte del día (mañana, tarde o noche).

El aplicativo es perfecto, cumple con todas las solicitudes de los stake-holders o interesados y tus jefes están sumamente contentos con el trabajo realizado.

Los usuarios finales deciden invertir para añadirle una segunda serie de funcionalidades y características a tu aplicativo, entre las cuales, está la posibilidad de indicar el peso total del paquete próximo a recibir porque los clientes quieren saber si es algo muy grande que deben manejar en la entrega.

Bien, el cambio no es difícil, es solo añadir una columna nueva en la base de datos, actualizar el esquema o clase en la lógica del backend y habilitar un campo en la interfaz del frontend para introducir esta información.

Tu plan para llevar a cabo esta actualización, y la de las demás funcionalidades y características, es actualizar los repositorios, por lo cual ya tus aplicativos frontend y backend tienen la nueva lógica, y para tu base de datos, decides que entrarás al servidor de producción y harás este cambio manualmente con un ALTER TABLE pedidos ADD peso_kg DECIMAL (16, 4).

Como podrás notar, esto de entrar a los servidores en producción es un ¡no no no! Existen muchos riesgos y peligros, créeme. Por más experimentado que uno sea, siempre va a ocurrir el error al momento de alterar o modificar algo en una base de datos en producción (por desgracia, aprendí esto a las malas).

La "migración" de la base de datos en tu aplicativo de correspondencia

Para resolver este inconveniente de actualización del esquema de la base de datos, creamos o "generamos" migraciones que se encarguen de alterar, añadir o eliminar objetos de tu base de datos de acuerdo al requerimiento de las nuevas versiones.

Pero recuerda esto super importante: así como en tu control de versiones en GitHub, GitLab, BitBucket, Azure Devops, o el servicio que estés usando, debe existir tanto una forma de subir o mejorar tu versión de base de datos ("upgrade"), como una forma de bajar o degradar la versión ("downgrade").

Entonces vamos a crear 2 métodos o funciones que hagan exactamente esto mismo:

1. La función de upgrade se encarga mejorar la base de datos desde la versión v1.0 a la v2.0.
2. La función de downgrade se encarga de degradar la base de datos desde la versión v2.0 a la v.10.

Puede suceder el caso de que un error inesperado afecta producción y la mejor solución es revertir todos los cambios y retornar a una versión anterior. En nuestro ejemplo sería regresar a la versión v1.0, por lo tanto es importante tener la función downgrade disponible.

Así como hacemos git revert para revertir cambios en el repositorio y retornarlo a un estado anterior, lo mismo logramos con el método downgrade.

Listo, de esta forma logras varios objetivos en tu aplicativo:

• Manejar tu base de datos con un control de versiones.
• Hacer actualizaciones de forma programada con cada salida o liberación de nueva versión de tu aplicativo.
• Tener un camino o vía para retornar los cambios en cualquier punto de tu aplicativo.

Si, a pesar de que es mayor trabajo al momento de desarrollar tu aplicativo, es la mejor forma de tener un control y trazabilidad completa de tu esquema de base de datos.

Ahora, ¿Hay algunos ejemplos prácticos que podamos usar en Node.js o Python?

Si, para esta pregunta te voy a presentar 2 ejemplos en Node.js, uno usando la librería Sequelize y otro usando la librería TypeORM. El último ejemplo lo haremos en Python con la librería Alembic.

De nuevo, todo el código referente a estos ejemplos lo encuentras en Migraciones con Node.js y Python

Aplicativo en Node.js (JavaScript) usando Sequelize

En este primer ejemplo creamos una aplicación desde cero en Node.js usando las librerias dotenv, express, pg, pg-hstore y sequelize. Como dependencias de desarrollador usamos las librerias de nodemon y sequelize-cli.

Como vamos a usar dotenv, creamos un archivo .env el cual tendrá la variable DATABASE_CONNECTION_URI = postgres://usuario:contraseña@localhost:5432/migrations_sequelize apuntando a la base de datos.

Creamos el archivo .sequelizerc para indicar los paths hacia los distintos archivos de configuración. En este ejemplo indicamos donde se encuentra el archivo config.js.

En el archivo config.js indicamos el objeto "development" para nuestras variables en el ambiente de desarrollo e indicamos los valores de url y dialect para nuestra base de datos.

Creamos el directorio migrations e indicamos nuestras migraciones creando documentos con el formato <timestamp>-<nombre-migracion>.js. Y en este archivo definimos las funciones up y down a ser exportadas donde está la lógica de subida de versión y bajada de versión de la base de datos.

"use strict";

/** @type {import('sequelize-cli').Migration} */
module.exports = {
  up: (queryInterface, Sequelize) => {
    // lógica para transformación a nueva versión
  },
  down: (queryInterface, Sequelize) => {
    // lógica para revertir los cambios
  },
};

Otra forma de crear este archivo es a través del uso de sequelize-cli, cuya herramienta nos permite usar el comando npx sequelize-cli model:generate --name MyModel el cual creará un archivo con el nombre <timestamp>-create-user.js en la carpeta migrations.

Nota: más información acerca de esta librería la encuentras en el portal de Sequelize Migrations.

Aplicativo en Node.js (TypeScript) usando TypeORM

En este segundo ejemplo creamos una aplicación desde cero en Node.js usando las librerias dotenv, express, pg, reflect-metadata y typeorm. Como dependencias de desarrollador usamos las librerias de @types/express, @types/node, nodemon, ts-node y typescript.

Con el uso de dotenv vamos a crear un archivo .env con la variable DATABASE_CONNECTION_URI = postgres://usuario:contraseña@localhost:5432/migrations_typeorm apuntando a la base de datos.

Creamos un archivo llamado data-source.ts donde usaremos la clase DataSource de typeorm. Adicionalmente importaremos todas las clases que representen un modelo de datos de las entidades del proyecto. Finalizamos el archivo exportando nuestro objeto AppDataSource con la configuración de nuestra fuente de datos.

Al ser un proyecto en TypeScript, también se debe configurar el archivo tsconfig.json, el cuál dependerá de cada proyecto o de tus preferencias en este framework.

Y por último creamos nuestros archivos de migraciones, los cuales llevan un formato parecido al de Sequelize: <timestamp>-<NombreMigracion>.ts (nótese el uso del formato Pascal Case).

import { MigrationInterface, QueryRunner } from "typeorm"

export class PostRefactoringTIMESTAMP implements MigrationInterface {
    async up(queryRunner: QueryRunner): Promise<void> {
      // // lógica para transformación a nueva versión
    }

    async down(queryRunner: QueryRunner): Promise<void> {
      // lógica para revertir los cambios
    }
}

Otra forma de crear este archivo es a través del cli usando el comando typeorm migration:create ./path-to-migrations-dir/PostRefactoring, el cual creará el archivo con el nombre de migración PostRefactoring usando el timestamp actual, para que puedas modificarlo a tu gusto.

Nota: más información acerca de esta librería la encuentras en el portal de TypeORM Migrations.

Aplicativo en Flask (Python) usando SQLAlchemy y Alembic

Y para nuestro último ejemplo creamos una aplicación desde cero en Flask usando las librerías Flask, SQLAlchemy, Flask-SQLAlchemy, Alembic, Flask-Migrate y psycopg2-binary.

En este aplicativo también podemos usar librerías para el uso de variables de entorno como lo es python-dotenv, sin embargo, en nuestro ejemplo nos saltamos esta parte. De todas maneras recuerda mantener la seguridad de tu aplicativo usando variables de entorno y secretos para las credenciales de los aplicativos. También para el caso de Flask vamos a crear un archivo config.py donde exportamos la clase Config con las variables SQLALCHEMY_DATABASE_URI = 'postgresql://postgres:password@localhost:5432/migrations_alembic' y SQLALCHEMY_TRACK_MODIFICATIONS = False.

El uso de Alembic para las migraciones tiene una lógica distinta a las de Sequelize y TypeORM: las migraciones no se crean a mano sino a través de cli (aunque éstas últimas también tienen la tienen opción, en Alembic es el método preferido). Entonces, en este caso usaremos el comando flask db init para inicializar nuestro sistema de migraciones, para luego usar el comando flask db migrate -m "Initial migration." y por último el comando flask db upgrade. En estos 3 pasos hemos inicializado la carpeta de migraciones (en el archivo app.py le hemos indicado al objeto migrate que usaremos el nombre de migraciones como carpeta).

En Alembic las migraciones van en la carpeta versions y no van enumeradas de menor a mayor a través del uso de timestamp o numeración con en las otras librerias, sino que se asigna una cadena hexadecimal de 12 carácteres o un "12 digit hex code", y el orden de las versiones se indica a través de las variables revision y down_revision dentro de cada archivo (pudiendo complicar a simple vista el orden de las migraciones para nosotros los humanos).

Dentro de cada archivo se encuentra el código a ejecutar para subir o bajar de versión.

"""Initial migration.

Revision ID: de3dad1e7bad
Revises: 
Create Date: 2024-06-26 12:26:49.288399

"""
from alembic import op
import sqlalchemy as sa


# revision identifiers, used by Alembic.
revision = 'de3dad1e7bad'
down_revision = None
branch_labels = None
depends_on = None


def upgrade():
    # lógica para transformación a nueva versión


def downgrade():
    # lógica para revertir los cambios

Y listo, usamos el comando flask db upgrade para actualizar nuestra base de datos para tener nuestro proyecto en Flask al día.

Nota: más información acerca de esta librería la encuentras en el portal de Flask-Migrate usando Alembic.

Conclusiones

Las migraciones de bases de datos son esenciales para mantener la integridad y la funcionalidad de una aplicación en crecimiento. Así como el código de una aplicación evoluciona, también lo debe hacer la estructura de su base de datos. Al implementar un enfoque estructurado para las migraciones, nos podemos asegurar que las actualizaciones y mejoras se realicen de manera controlada y reproducible, minimizando el riesgo de errores en producción. Esto es especialmente crucial en entornos donde la precisión y la consistencia son fundamentales, como en sistemas que manejan grandes volúmenes de datos o que tienen requisitos regulatorios estrictos.

Incorporar tanto las funciones de "upgrade" como de "downgrade" en el proceso de migración no solo permite mejorar la base de datos, sino también revertir cambios en caso de errores, así como también el uso de herramientas como Sequelize, TypeORM y Alembic hace que la creación y gestión de migraciones sea más accesible y menos propensa a fallas.

Y finalmente, adoptar un enfoque proactivo en la gestión de migraciones refuerza el compromiso de un equipo de desarrollo con la calidad y la estabilidad del software. A medida que las aplicaciones crecen en complejidad y alcance, la capacidad de gestionar cambios en la base de datos de manera eficaz se convierte en un diferenciador clave.

TLDR: Creé mi primera página web para mi marca personal y me faltó configurar el correo electrónico. Son 2 tipos de envío de correo que usa Ghost: 1) emails transaccionales para registrarse en el portal o solicitud de correo para reinicio de contraseña (a través de SMTP), y 2) emails de marketing para el envío de newsletter (a través de una API para correos masivos -bulk-). Intenté configurar Mailgun como se recomienda en la documentación, pero me salté un detalle y como tampoco quiero hacer mucho énfasis en el Newsletter, elegí AWS SES como proveedor de envío de correos y sólo dejé configurado los envíos transaccionales.

¿Mailgun o AWS SES?

Al momento de levantar un portal de Ghost, una parte fácil de dejar de último es la elección de proveedor de envío de correos, entonces ¿qué significa esto?. Recuerda que tu portal tiene la opción de crear usuarios para suscriptores o recibir un Newsletter apenas un post haya sido publicado.

La documentación de Ghost favorece Mailgun y explica que es muy fácil crear una cuenta, por lo que inicialmente elegir esta opción suena muy fácil, y más cuándo te menciona que tiene una suscripción de "pay-as-you-go", la cual cobra por cada correo enviado. Y adicional suma al hecho de que Mailgun no cobra cuando la factura es menor a $ 0.50 en USD, por lo que podemos decir que tenemos alrededor de 600 envíos de correos de forma gratuita.

Pero parte de esta información, para hoy 18 de abril de 2024, está un poco desactualizada.

Actualmente no hay forma de elegir el plan "pay-as-you-go", o no aparece entre las opciones de plan, por lo que se debe empezar desde el más económico de $ 35.00 para una capacidad máxima de 50,000 correos, lo cual no es gratis como podemos leer.

Esto hace que Mailgun no suene tan favorable. Y como por ahora el envío de Newsletter no es primordial, podemos obviarlo y configurar algún servicio para sólo los correos transaccionales, lo cuál se explica más adelante.

Por lo que respondiendo a esta pregunta: si quieres enviar todo tipo de correos, transaccionales y de marketing, configura Mailgun (incluso en la última sección te explico como crear una cuenta "pay-as-you-go" actualmente), y si solo necesitas para el manejo de usuarios, solo correos transaccionales, entonces configura AWS SES, o Gmail, o Mailchimp, o cualquier otro servicio que desees.

Pero, ¿qué son correos transaccionales y qué son correos de marketing?

La administración de usuarios creados con el correo electrónico requiere enviar información privada para verificar la dirección o enviar un email para cambiar la contraseña con algún token. Este tipo de comunicación son correos transaccionales y es parte vital de cualquier portal.

Cuando queremos enviar emails con una vista o invitación a leer el último post, información privada que es sólo para ciertos miembros, o simplemente enviar un correo para publicidad, a esto se le llama correo de marketing.

Ghost solo permite el servicio de Mailgun para el envío de correos de marketing, y tienen varias razones explicadas en su portal, y el TLDR: Mailgun usa mecanismos para evitar que los servidores de correos sean clasificados como spam.

Entonces, ¿cómo configuro AWS SES?

Una vez decidido es simplemente entrar a nuestra cuenta de AWS, ir a la sección de SES (Simple Email Service) y registrar nuestro dominio. En el post pasado explicaba el uso de AWS Route 53 y la adquisición del dominio a través de Namecheap. Como la configuración de los servidores de Namecheap apunta a los servidores de AWS, específicamente hacia los de Route 53, registrar el dominio en AWS SES es muy fácil, sobre todo porque al ser servicios de Amazon, de una vez los datos de los servidores y demás son registrados de forma automática.

Una vez registrado, es sólo esperar que se haya verificado el dominio y listo, ya tenemos esta parte configurada, ya podemos enviar correos de parte de jorgetech.dev. Ahora nos queda probar, pero para eso, tenemos que verificar una cuenta de correo electrónico.

AWS SES también permite verificar correos electrónicos, comprobar que nos pertenece y enviar mensajes con el correo verificado como destinatario, pero esta no es la razón de verificar el correo. Resulta que al registrar tu dominio, este aún continúa estando en un ambiente de Sandbox, o de pruebas, y solo es posible enviar correos a direcciones autorizadas o verificadas. Es más un tema de seguridad que otra cosa, y la forma de salir de este ambiente y transformarlo a uno de producción, es haciendo la solicitud a AWS. Recuerda que esto sube los topes de tus mensajes.

Teniendo registrado el dominio y con correo electrónico (puede ser uno personal), podemos enviar correos de prueba para verificar que todo está funcionando como debería. Una vez todo parece ir bien, lo que falta es solicitar salir del ambiente Sandbox.

Abrir un caso en AWS para salir de ambiente Sandbox

Esta parte es la más "personal", y digo personal, porque es un correo que una persona debe verificar y autorizar, o eso parece.

Mientras estás en el Dashboard de SES puedes ver un cartel azul aparecer indicando abrir un caso solicitando la salida del ambiente Sandbox. En el caso, se debe seleccionar si el uso del correo es para transacciones o para marketing. La idea es colocar una descripción de para qué vas a usar el correo, cómo piensas manejar la distribución de correos, cómo vas a manejar los usuarios, que proceso tienes para cuando un usuario no quiere recibir correos o el famoso botón de "unsubscribe" y demás.

Una vez creado este caso o ticket, te llegarán correos con la apertura de tu caso y probablemente te pidan más detalles. Una vez transcurra un tiempo entre 24 y 48 horas, te responderán con los términos y condiciones y la aprobación de la salida de ambiente Sandbox.

A partir de aquí, puedes eliminar tu correo personal como verificado y volver a probar desde SES. Sólo queda pendiente la configuración Ghost.

Configuración de correo en Ghost

Acá es sencillo, es ingresar a la instancia EC2 a través de SSH y buscar el archivo de configuración de ghost para cambiar algunos valores. Este documento está en la dirección /opt/bitnami/ghost/config.production.json y en el portal de Bitnami puedes encontrar más información de configuración.

Recuerda que este es el archivo JSON de configuración de Ghost para varias opciones, como las credenciales de la base de datos o la url de la página.

Luego, puedes ir al portal administrativo de Ghost e intentar ingresar al portal administrativo, dar click en el botón de "Forgot password" y esperar que el correo de reinicio de contraseña llegue tu bandeja, y listo: ya tienes configurado tu sistema de correo en Ghost.

¿Y cómo hago para crear una cuenta Mailgun con el plan "pay-as-you-go"?

Listo, entonces queremos crear una cuenta en Mailgun, pero no queremos pagar por un plan por una capacidad máxima de mensajes, sino pagar por lo que usamos. Tener disponible 50,000 mensajes para alguien que está empezando es demasiado.

En el portal de Ghost indica que se puede obtener una cuenta "pay-as-you-go", pero no indica exactamente cómo.

Alguien ya indicó en los foros de Ghost que no es posible abrir una cuenta y seleccionar la opción de pagar a medida que se usa, y preguntando qué opciones habían, se le respondió como hacer para obtener este plan: al momento de crear una nueva cuenta, llenar el formulario del método de pago, seleccionar un mes de prueba gratis, usar el servicio por unos días y luego darse de baja del plan, por lo que automáticamente la plataforma te asigna en el plan de "pay-as-you-go". De esta forma no se cobra por ningún plan y puedes usar el servicio pagando por los mensajes que envíes, pero si estos son menos de aproximadamente 600, puede que no se te facture al respecto.

En este enlace tienes toda la información del caso y las respuestas que estamos mencionando.

El error que cometí fue que creé la cuenta directamente y ya no me es posible seleccionar una prueba por un tiempo o trial, por lo que debo cancelar mi cuenta, esperar un tiempo y volverla a crear con la opción de prueba, usarla unos días (antes del corte) y luego cancelar la suscripción para que se me asigne el plan que deseo.

En resumen, el portal ya se encuentra habilitado para suscribirse. Por los momentos no tengo un plan de Newsletter o secciones exclusivas para miembros, pero si deseo añadir esto en un futuro, dependiendo de como vayan las cosas.

Si tienes alguna duda de cómo hacer alguno de estos pasos, déjame saber y con seguridad podemos resolverlo. !Feliz día!

TLDR: Quise crear mi propia página web tipo Blog, usando alguna tecnología que fuera novedosa, descartando viejos conocidos en PHP como WordPress o Drupal. También quise implementar el proceso de levantamiento usando algún servicio de cómputo en la nube como AWS o Vercel. Terminé eligiendo Ghost como tecnología, descartando el servicio que ellos ofrecen para los blogs y creando una instancia en AWS EC2. No salió como esperaba, tuve unos inconvenientes y me apoyé con unas imágenes ya existentes de Bitnami para la puesta en servicio. Lo demás fue configuración y aquí estamos.

Elección de Ghost (razones personales, puedes saltar esta sección)

Primero, dentro de lo que quería hacer, investigué varias herramientas para creación de páginas web (no solo blogs) que sean contenidas en un solo aplicativo (backend y frontend en el mismo despliegue) y que estén basadas en node.js.

En el mundo de node.js no hay muchas opciones, las más relevantes son Headless CMS: Strapi y Directus. Dos espectaculares opciones que llegan hasta ese punto, el de Headless.

Estas 2 opciones poseen todo lo que uno necesita para administrar contenido: manejo de usuarios, permisos, documentos, imágenes, rutas, etc. Sin embargo, como su nombre indica, son Headless, o lo que en la practica traduce, sólo es el backend o la administración del contenido. Para mi solución, quería desplegar usando un solo proyecto o repositorio, y a pesar de que podía iniciar un proyecto en React.js o Next.js con alguna librería como MUI, no quería llegar hasta ese punto o complicación.

Otro punto a tomar en cuenta, es que en el trabajo estábamos evaluando un cliente el cuál insistía con un CMS completo, que a su preferencia, quería usar WordPress. Desde el departamento sabemos que estas tecnologías ahorran en esfuerzo a la hora del despliegue, pero dificultan (y en gigantes rangos) el proceso de integración y crecimiento propio de la solución, pero en nuestra opinion, esta es la principal razón por la que aún no logramos superar PHP como lenguaje: proyectos completos como WordPress o Drupal nos enamoran para su uso, alejándonos de lenguajes de programación más eficientes, óptimos y con mejores curvas de aprendizaje.

Nunca había escuchado Ghost, y a pesar de que al inicio tuve algunas confusiones acerca de cómo resuelve el contenido, me gustó saber que:

• Es un CMS que permite generar páginas y posts.
• Posee una interfaz completa para la creación y edición de contenido.
• Está enfocado a páginas por suscripción, sin embargo, esto es opcional.
• Posee Newsletter, lo cuál permite crear campañas de correos personalizadas.
• La interfaz está impulsada por Handlebars, lo cuál es una tecnología fácil de conocer.
• Existen varios temas gratuitos y otros más que pueden adquirirse por un precio, que complementan y mejora todo lo que Ghost puede hacer.
• Las rutas, lenguajes, tags y otros elementos pueden personalizarse.

Y queriendo usar algún lenguaje de fácil uso para mi como node.js, está fue una elección fácil que me entusiasmó. Pero igual, les recomiendo tomar en cuenta las contras:

• Manejo de un sólo Content-Type (posts).
• No posee integración nativa con servicios de archivos o media files como AWS S3.

De todas maneras, sigo pensando que es una buena solución para portales sencillos: blogs personales, páginas de empresas, información de podscasts o eventos, etc.

Elección de AWS (también personal, puedes continuar con la siguiente sección)

Este es un tema un poco más directo que la elección de Ghost. Durante mi carrera, he trabajado con uso de cómputo en la nube con los proveedores Azure y AWS. Cada uno tiene sus pros y contras, sin embargo, en mi día a día actual, es más frecuente la elección de AWS debido a que su principal ventaja es la economía de precios (o eso aparenta).

Sin ahondar mucho, me gusta probar y saber qué y qué no se puede hacer con este servicio de cómputo en la nube, y con el ofrecimiento de 750 horas de cómputo gratis durante un año, me parece una buena opción.

El portal de Ghost ofrece un servicio de despliegue de tu portal (TryGhost), con tu propio dominio, por $ 9.00, el cual es un buen precio a mi parecer, pero sigo pensando en que quiero desplegar mi propia solución.

Como dije al inicio, quería hacer un despliegue desde sus inicios, usar las tecnologías de AWS y aprovechar las 750 horas ofrecidas, por lo que de una vez tomé esta opción.

Primeros pasos y fallos

Bien, ya pongámonos en modo programador y despleguemos nuestro propio portal.

Antes de iniciar, debo adquirir mi propio nombre de dominio o DNS (Domain Name System), que es cómo voy a ser conocido en el internet. Me dirigí a Namecheap y adquirí jorgetech.dev por la módica suma de aproximadamente $ 11.00.

Crear mi primera instancia de AWS EC2

Listo, ahora simplemente creo una instancia en AWS EC2 con una imagen en Ubuntu y hago la instalación. Todos los pasos se encuentran en la página de Ghost. Ya había "jugado" con esta tecnología en local, por lo que simplemente era instalar en mi nueva máquina virtual, subir el tema de mi elección (desde la tienda o personalizado) y listo, ¿suena fácil no?

En primer lugar, accedí a mi cuenta de AWS, me dirigí a la sección de EC2 e inicié una instancia micro (permitida para las 750 horas gratuitas) usando la imagén de Ubuntu que había mencionado. En menos de 5 minutos, ya podía conectarme a través del protocolo SSH a mi máquina virtual (recuerden crear las credenciales necesarias para la conexión).

Listo, entonces es solo ingresar y seguir los pasos:

1. Crear un nuevo usuario.
2. Actualizar todos los paquetes.
3. Instalar NGINX.
4. Instalar MySQL.
5. Instalar Node.js.
6. Instalar Ghost-CLI.
7. Crear el directorio y habilitar los permisos para el usuario de la máquina.

Y listo, ya solo falta el paso 8, instalar Ghost.

8. Instalar Ghost con el comando ghost install.

Aquí es donde todo no correo como esperamos. Esta instalación nunca ocurre, la máquina virtual dura horas instalando Ghost hasta que se pierde la conexión. Pensé que era un problema de falta de memoría física (AWS EBS), por lo que repetí la creación de la instancia dejando a la máquina con 50 GB de memoria, pero aún así, la instalación se congelaba.

Probando con otras imágenes oficiales de AWS

Al momento de crear una instancia, tenemos otras opciones para la imagen, desde Linux, Debian, una versión creada específicamente por Amazon, hasta instalar Windows o MacOS.

Obviamente todos los intentos fueron con las distribuciones de Linux (donde los comandos no son siempre iguales), sin embargo, sucedía lo mismo: siempre se congelaba en el paso 4 o 5 de la instalación de Ghost.

Por lo que ya había que recurrir a la magía del internet. Resulta que este problema, no era único para mi. Como pueden ver en el post, varios usuarios reclamaban el mismo inconveniente, por lo que eran un mensaje en Github donde un usuario indicaba que este inconveniente era porque la máquina virtual sólo tenía 1 GB de memoria RAM y se necesitaban mínimo 2 GB. Esto era contradictorio a la página de Ghost, donde se indica que mínimo, 1 GB de memoria RAM es suficiente.

Lástima, todo parecía muy sencillo. Luego de esto, sólo quedaba la configuración de NGINX, el dominio y los certificados.

Esto fueron varios intentos, cada uno durando entre 1 hora y 3 horas. Al 3er día me rendí con esta opción y empecé a buscar alternativas.

Pude haber elegido Digital Ocean para el despliegue, o directamente adquirir el servicio desde la página de Ghost, sin embargo, quería insistir con esta opción. Dudo mucho que hayan clientes pequeños en mi trabajo para proponer esta opción, pero quien sabe, nunca está de más tener esto en el arsenal (al menos una landing page con redirecciones puede ser muy fácil para vender).

Y aquí es cuando descubrí las bondades de desplegar una instancia usando imágenes de terceros, como los el proveedor Bitnami, quien justamente para Ghost tienen una imagen de uso gratuito.

Tutorial o guía de despliegue de Ghost en AWS EC2 con uso de una imagen de Bitnami

Vamos a seguir los pasos de manera general de como instalar Ghost en AWS usando una imagen de instancia de Bitnami:

1. Ingresamos a nuestra cuenta de AWS, nos dirigimos a la sección de EC2 y seleccionamos crear una instancia.
2. En la sección de imagen, nos vamos a la sección de imágenes de terceros.
3. Buscamos Ghost de Bitnami y seleccionamos la que necesitamos.
4. Seleccionar un "key pair" para la instancia (para la conexión a través de SSH).
5. Seleccionar un "security group" que permita conexiones desde cualquier IP (Anywhere).
6. Configurar unos 30 GB de storage EBS.
7. Esperamos por la finalización del despliegue y luego nos vamos a los mensajes de Log de la instancia.
8. Buscamos la sección donde se inicia el usuario y contraseña para ingresar. Este proceso es para obtener las credenciales para ingresar al aplicativo por primera vez: encuentra las credenciales de la aplicación.
9. En la sección de Getting started puedes obtener información adicional de cómo ingresar a la base de datos o la configuración inicial de Apache.
10. En la sección de Configuration hay información adicional para otras configuraciones del servicio SMTP o Apache.
11. En la sección de Administration se encuentra la mayor porción de información para el servidor en Ghost.
    1. Esta sub-sección te muestra los comandos para iniciar, reiniciar o detener los servicios de Ghost.
    2. Sub-sección a seguir para configurar el dominio del servidor.
12. En esta guía se encuentra la información para configurar los certificados SSL y el DNS a través de HTTPS.
13. Crear una Elastic IP desde AWS y asignarla a nuestra instancia de Ghost.
14. También se debe configurar el DNS (para mi caso usé Namecheap en la compra de mi dominio). Este proceso es sencillo y directo. Cuando estés configurando el dominio, ve a la sección de "Advanced DNS" para el dominio y crea un "A Record". Selecciona "Host" como "@" e introduce el Valor de la Elastic IP que configuraste antes. Guarda esto y crea un segundo "A Record", selecciona "Host" como "www" y introduce el Valor para que sea el mismo del Elastic IP que configuraste antes.

Hay varios puntos y fuentes de información adicional que dejaré por acá para vuestro interés:

• Readme en Github por el usuario bdeitte donde explica el proceso de configuración de Ghost con AWS y Namecheap.
• Consulta en Stack Overflow donde se concluye que para la instalación de Ghost se requieren 2 GB de memoria RAM en vez de 1 GB.

Se que hay otros datos importantes, sin embargo, si presentas un inconveniente durante la instalación, déjame saber para ayudarte o guiarte durante el proceso.

Este es mi blog, de parte de Jorge. Es un nuevo lugar para todos esos temas, pensamientos, tutoriales, ejercicios, pruebas de concepto e historias que quiero compartir sobre la programación de aplicativos web, softwares, tecnologías y demás.

Soy programador de aplicativos web, por lo que hay muchas ideas que quiero que conozcan y tal vez si uno o varios aprenden algo al respecto, me sentiré más que conforme. También quiero mostrar de lo que soy capaz y tener un lugar donde demostrar todos mis conocimientos.

Esto apenas está empezando, así que prepárate y recuerda, si quieres ver algún tema en específico, sólo déjame saber.