Pensamientos detrás del lanzamiento de este blog
Comparto mis reflexiones al lanzar este blog: desde el propósito inicial hasta la elección de frameworks frontend y sistemas de gestión de contenido desacoplados (headless CMS).
He recopilado mis pensamientos iniciales al lanzar este blog.
【Propósito】
Al escribir sobre las tecnologías que voy adquiriendo, busco consolidar una comprensión precisa y profunda de la tecnología y, como beneficio adicional, intentar monetizar el sitio para complementar los fondos de mantenimiento del servidor. Por lo tanto, las prioridades son las siguientes:
- Adquirir la tecnología más reciente.
- Mantener los costos operativos lo más bajos posible. Si los gastos superan los ingresos, continuar se vuelve difícil.
- Minimizar los esfuerzos ajenos a la redacción, como las tareas de mantenimiento y la publicación de artículos.
- Se planea que el contenido de los artículos sea principalmente técnico, seguido de pasatiempos.
【Consideraciones sobre el entorno de operación】
Listé los métodos de operación para iniciar un blog.
<Desventajas de los sitios gratuitos>
- No contribuyen a adquirir la tecnología más reciente.
- Los sitios gratuitos muestran anuncios automáticamente, aumentando las visualizaciones que no generan ingresos propios. Además, pueden mostrarse anuncios no deseados.
- Dado que es una plataforma de blog dedicada, el esfuerzo de configuración probablemente sea mínimo.
<Desventajas de los sitios de pago>
- No contribuyen a adquirir la tecnología más reciente.
- El problema es que cuestan dinero. Hay una alta probabilidad de abandonar el proyecto sin continuar.
- Probablemente requieran la menor cantidad de esfuerzo administrativo.
<Independiente: WordPress + Servidor local + Cloudflare Tunnel>
- Solo Cloudflare Tunnel es una novedad.
- Básicamente gratuito, por lo que es fácil de mantener a largo plazo.
- El propio WordPress se ha vuelto muy complejo, lo que tiende a complicar la gestión, como las actualizaciones de artículos, conllevando ciertos costos de aprendizaje. *¿Dentro de un rango aceptable?
<Independiente: Framework de JS + GitHub + Headless CMS + Cloudflare Pages>
- Gestión de contenidos mediante un Headless CMS, un tipo moderno de CMS, combinado con un framework de JS.
- Básicamente gratuito, por lo que se cumple el objetivo.
- Operar mediante SaaS es cómodo, pero si el servicio cierra, te quedas atascado. Aumenta los costos y el esfuerzo de migración.
【Entorno de desarrollo】
Por lo tanto, basándome en las consideraciones anteriores y la información de los frameworks que detallo abajo, y como parte de mi aprendizaje para futuros desarrollos de aplicaciones a gran escala, decidí intentar construir un sitio de blog con un framework de frontend + headless CMS + Cloudflare Pages.
<Sobre el editor>
Para el desarrollo de código, es común instalar un entorno de desarrollo integrado (IDE) y añadir extensiones adecuadas. VS Code es óptimo, pero como el editor ligero y rápido Zed ya implementa extensiones para Astro, usaré este último.
<Entorno de escritorio para desarrollo>
El desarrollo de código requiere la integración con otros servicios en la nube como npm (Node Package Manager) y GitHub. (Referencia: npx significa "Node Package Execute". A diferencia de npm, es una herramienta de línea de comandos para ejecutar temporalmente paquetes de Node.js sin tener que instalarlos, ejecutándolos sin ensuciar el entorno de desarrollo.)
Tipo de SO | Características |
Linux | Se dice que aproximadamente el 70% de los servidores web del mundo son Linux. Tiene una alta cuota en servidores y la mayor cantidad de herramientas de desarrollo. Sin embargo, el refinamiento de la interfaz gráfica de usuario (GUI) y el soporte de aplicaciones de escritorio son significativamente menores en comparación con Mac o Windows, lo que lo hace menos idóneo como máquina principal del desarrollador. |
macOS | Desarrollado originalmente como un sistema operativo de tipo Unix, tiene compatibilidad nativa con comandos de Linux y la mayoría de ellos se pueden utilizar directamente. La interfaz de escritorio es excelente, por lo que es la opción elegida por muchos desarrolladores. |
Windows | Su cuota de mercado en el ámbito comercial y de uso general es abrumadora. Al ser también apto para videojuegos, tiene la mayor cuota de computadoras de escritorio. Al instalar WSL (Windows Subsystem for Linux), puedes disponer de un entorno Linux completo sobre Windows. Básicamente ejecuta Linux como máquina virtual y comparte archivos, reuniendo lo mejor de ambos mundos. Desde la versión 2.0, son muchos los usuarios que lo utilizan. |
Un entorno de blog no requiere un sistema de desarrollo muy avanzado, por lo que tanto Mac y Windows son adecuados. No obstante, para ahorrarme la molestia de instalar WSL, procederé con macOS en esta ocasión.
【Dev Container】
En desarrollos con múltiples colaboradores, es común unificar el entorno utilizando DevContainers. Sin embargo, honestamente, introducir DevContainers en un entorno de desarrollo personal como un blog parece más problemático de mantener que de configurar directamente, por lo que he decidido posponerlo por ahora.
【Características de los frameworks de frontend】
Generalmente, un conjunto de funciones convenientes y bibliotecas compiladas bajo una "filosofía de diseño" para construir un sitio web se denomina framework. Seguir esa filosofía de diseño al escribir código hace que el desarrollo sea eficiente. Aunque requiere comprender la filosofía y aprender las particularidades del código, una vez aprendido se genera una consistencia en toda la implementación, haciéndolo más legible y con menor tendencia a fallos, lo que lo convierte en un elemento esencial para sitios de gran tamaño.
Nombre del framework | Creador | Características |
React (Muchos usuarios) | Meta (Facebook) | La interfaz se gestiona basada en componentes y el renderizado es rápido porque solo se actualizan los cambios a través del DOM virtual. Se asemeja más a una biblioteca de interfaz de usuario que a un framework completo. *Personalmente no me gusta |
Vercel | Un framework full-stack basado en React. Mientras que React actúa únicamente en el lado del cliente, este incluye el lado del servidor, lo que permite métodos de renderizado óptimos y una visualización más rápida. *¡Actualmente obsoleto! (El CEO es una basura, así que ya no me gusta) | |
Vue.js (Muchos usuarios) | Evan You | Ideal para desarrollo individual por su baja curva de aprendizaje. Permite hacer mucho mediante diversas combinaciones. Basado en componentes y muy flexible al integrarse con otras bibliotecas. Cuenta con abundante documentación. Personalmente me gusta. |
Alexandre Chopin, etc. | Un framework full-stack basado en Vue.js. Especialmente optimizado para construir sitios web tipo SPA (Single Page Application). | |
Astro Technology Company | Astro renderiza toda la página en HTML estático y maximiza el rendimiento eliminando el JavaScript innecesario. Diseñado para permitir el uso concurrente de diferentes frameworks de interfaz como React o Vue. Más orientado a MPA que a SPA, la carga inicial de la página es sumamente rápida. El framework idóneo para un blog. |
<Referencia>
- Resultados de la migración de Next.js a Astro
- React posee derivados como React Native, que permiten crear aplicaciones móviles nativas. Al proporcionar servicios multiplataforma, el costo de aprendizaje se amortiza rápidamente.
- No obstante, para el desarrollo multiplataforma en iOS y Android, Flutter de Google tiene actualmente más fuerza que React Native. Dado que comparte la interfaz de usuario, la experiencia de uso no cambia según el dispositivo, resultando muy conveniente para aplicaciones comerciales. Por lo tanto, no veo motivos para forzar la adopción de React.
【Headless CMS de código abierto (gratuitos)】
No existen muchos tipos de Headless CMS de código abierto diseñados para ser alojados en servidores propios. Al igual que microCMS, muchas empresas los ofrecen como servicios SaaS en la nube. Sin embargo, el código abierto tiene grandes ventajas si deseas conservar tus datos de manera interna o si te preocupan las tarifas al escalar. Aun así, se requiere un servidor propio.
Nombre | Características |
Probablemente el Headless CMS de código abierto más famoso. Licencia MIT. Gratuito tanto para uso personal como comercial, aunque dispone de una versión de pago con más funciones. *Parece estar basado en React. | |
Sanity | Su punto fuerte es un esquema de datos flexible y la edición colaborativa en tiempo real. Excelente para la gestión de contenido dinámico. Tipo nube (SaaS) con plan gratuito disponible. |
Escrito en JavaScript, se ejecuta en Node.js. Distribuido bajo licencia MIT. Cuenta con imagen oficial en Docker Hub. Un Headless CMS especializado en sitios web tipo blog, con una estructura cercana a la de WordPress. | |
Anteriormente conocido como Netlify CMS. Licencia MIT. Hay pocos artículos en español al respecto. Basado en Git, se conecta directamente con el repositorio de código. | |
Muy adoptado en grandes empresas. Escrito en JavaScript, se ejecuta sobre Node.js. Transforma bases de datos SQL existentes en APIs de alta velocidad de forma automática. | |
Basado en Python. Utilizado por la NASA y Google. | |
La base de datos parece estar limitada a MongoDB. Basado en JavaScript. | |
Utilizado por Unity. Licencia Apache 2.0. | |
Desarrollo corporativo. | |
Licencia GPL 3.0. Guarda la información en archivos JSON sin necesidad de usar una base de datos. |
<Selección de Headless CMS>
Básicamente, al tratarse de un blog personal que solo puede mantenerse si es gratuito, la búsqueda se reduce a los sistemas de código abierto con licencia MIT como Strapi, Ghost y Directus. Entre ellos, Strapi me pareció el más idóneo para futuras expansiones y comercio electrónico, así que me decidí por este último.
【Conclusión】
De este modo, elegí la combinación de Astro + Strapi + AlloyDB (PostgreSQL) + TailwindCSS + Cloudflare Pages + MacBook Pro + editor Zed como la base tecnológica para este blog. La clave reside en el flujo de construcción.
- Iniciar el contenedor de Strapi en la Mac y redactar los artículos.
- En el proceso de build, copiar las páginas estáticas y las imágenes desde Strapi, prescindiendo de Strapi en el entorno de producción (¡sin necesidad de un servidor activo en internet!).
- Desplegar el conjunto de datos estáticos generados en Cloudflare Pages. El sitio web final es puramente estático con un mínimo de JavaScript. La velocidad de carga es increíblemente rápida.
Lo crucial es que el entorno de producción consta únicamente de datos estáticos. Es como si utilizáramos Strapi solo a la hora de escribir los artículos.