Published on

De WordPress a Headless: Documentando la Aventura (Parte 1)

Autores

Luego de un fallido paso por el mundo de las startups, me vi nuevamente en el camino del desarrollo, esta vez como webmaster (si cabe el término) de un e-commerce. Luego de mucho aprendizaje, prueba y error, retrasos, pandemia, cuarentena, ataques DDoS y más, la tienda fue mejorando hacia un punto en que sin necesidad alguna (edit: Google ya nos dio motivos) me veo en la obligación de evolucionar la arquitectura de la misma (WordPress corriendo sobre un clásico LAMP Stack) y abrazar el Jamstack. A lo largo de estas publicaciones iré documentando el proyecto: como llegué hasta acá, lo que he aprendido y cuáles serán los siguientes pasos.

¿Cómo llegué acá?

Allá por los lejanos 2019, @pedepepe me preguntó si estaría interesado en estar medio tiempo haciendo mejoras a un e-commerce lanzado en año anterior. Con muchas ganas, poca experiencia y todo el carisma que una persona con ansiedad social pueda reunir, 48 horas después estabamos, mi laptop y yo, a cargo de la infraestructura tecnológica del e-commerce de la empresa.

Estado inicial

A pesar de los mejores esfuerzos de @pedepepe, la tienda requería dedicación a tiempo completo:

  • Estaba desarrollada en WordPress con el tema ByHands cuya última actualización fue el 2017. Además se habían realizado modificaciones directas en el código de algunos plugins, por lo que cualquier actualización rompía el sitio.

  • Problemas de fugas de memoria en la base de datos.

  • PLUGINS PARA T O D O ! ! !

Ahora pasando al estado inicial mío: venía con muchas ganas y un poco de experiencia en WordPress, el año anterior había llevado un curso de JavaScript del cual me acordaba muy poco, desempolvé los conceptos de PHP que había aprendido años atrás, estaba en medio de un freelo bastante grande (que meses después acabaría muy mal).

Primeros pasos

Empecé poniendo las cosas en orden: la arquitectura corre sobre AWS así que creé la nueva base de datos en RDS (y ya que estaba por acá, por qué no probar Amazon Aurora) y manos a la obra!.

Quizás la parte más complicada de este punto fue la migración de las órdenes antiguas puesto que en WooCommerce cada pedido nuevo es un post, por lo tanto se le asigna un número de ID correlativo al de la base de datos, es decir, puedes tener dentro de tu lista de órdenes lo números 100, 101, 102... y luego subes una nueva imagen, la base de datos le asignará el ID 103, por lo tanto el siguiente número de orden que ingrese será el 104; para continuar con la numeración correlativa en el nuevo ambiente y no complicarme con los números de ID opté por utilizar un plugin que funcionó muy bien... los primeros días y luego me generaría horas de estrés al causar conflicto con la pasarela de pago precisamente por una discrepancia entre el número de orden y el ID. Solución: actualizar los IDs manualmente en la base de datos (son cerca de 7 tablas por ID para los curiosos). Si alguien tiene una mejor solución, les agradecría que me la compartan ^_^.

Ahora por el lado del front, el tema fue desarrollado con la plantilla de HTML5 Blank y para acelerar un poco el tiempo de desarrollo utilicé Elementor Pro, maquetador visual muy ligero y que cuenta con componentes fáciles de implementar, decisión que 2 meses después me traería algunos problemas de seguridad. Como si no tuviera suficiente estrés encima, entre revisiones, correcciones y demás cambios llegó la gran cuarentena global... finalmente el proyecto no podía esperar más y lancé la versión 2 del e-commerce.

Mi Primer Ataque DDoS

El 4 de mayo se descubrió una vulnerabilidad en Elementor Pro que permitía a cualquier atacante subir archivos infectados hacia la carpeta Uploads lo cual eventualmente permitiría la ejecución de código malicioso. El día siguiente haciendo la verificación de seguridad habitual encontré 3 archivos extraños en la carpeta de medios de WordPress (aún no sabía de la alerta de seguridad), los eliminé al momento, hice un backup e instalé Wordfence para reforzar la seguridad del sistema, encontrando con sorpresa que tenía archivos en wp-content y wp-includes que no correspondían, Wordfence hizo lo suyo y realizó una limpieza asegurando la integridad de los archivos de instalación originales. Dos días después, el 7 de mayo se actualizan los plugins de Elementor y Elementor Pro, una nueva revisión de seguridad donde al parecer todo estaba bien, para luego horas después recibir como mensaje de bienvenida Error al establecer una conexión con la base de datos: estaba bajo mi primer ataque DDoS.

Como era de esperarse, estuve a la altura de la situación: las manos me temblaban y no podía escribir lo más básico, olvidé por completo todos los comandos del CLI de Linux y solo atinaba a reiniciar el servicio de Apache una y otra vez para tener unos segundos de disponibilidad antes que el servidor se vuelva a llenar de solicitudes. Error de novato y por exceso de confianza, pensar que nunca me iba a pasar a mi, los ataques DDoS son para las grandes empresas y en todo caso, "el hosting es Amazon, ellos deben tener todo solucionado". Por suerte @gcavanunez me pudo dar una mano y pasé el resto del mes en castigo autoimpuesto aprendiendo sobre políticas de seguridad, aplicando buenas prácticas... y también instalé Cloudflare cosa que debí hacer desde un inicio. Hace 3 semanas tuve otro ataque DDoS y en menos de 2 minutos tenía activada la protección para mitigación de ataques por lo que no hubo interrupción en el servicio.

Perdiendo la cabeza

Por aquellos meses empezaba a notar ciertas páginas que me cargaban casi de inmediato; una rápida inspección a Wappalyzer revelaba en muchos casos un framework llamado GatsbyJS, algo de lo que hace un tiempo atrás me había hablado @gcavanunez. Bueno pues, me propuse el reto de hacer mi primera página usando este framework, ¿qué tan difícil podría ser?.

Antes de empezar con Gatsby, debía conocer bien ReactJS...

Y aún antes de eso, dominar JS.

Lejos de desmotivarme... no, realmente sí me desmotivé mucho tenía mucho camino por recorrer antes de poder hacer páginas ultra veloces y con puntaje casi perfecto en Lighthouse, pero era avanzar o quedarme estancado. Finalmente, luego de muchos tutoriales y fines de semana completos frente a la PC, a mediados de setiembre publicaba mi primera página en Gatsby con lo aprendido hasta el momento.

Quizás en alguna sesión de lectura noctura debo haberme cruzado con la palabra headless y su apicación en el e-commerce. Apenas acababa de hacer una página estática en Gatsby ¿y ya quería hacer un e-commerce?.

La respuesta es SÍ.

Qué es y cómo funciona

Cuando trabajamos con un CMS tradicional o monolítico como es el caso de WordPress, interactuamos con un gestor para crear o subir contenido a la plataforma y con WooCommerce se extienden estas funcionalidades permitiéndonos crear un e-commerce desde donde gestionar nuestros clientes y pedidos. Por otro lado tenemos tenemos una guía predefinida para crear el front-end de manera dinámica así como las funcionalidades personalizadas que necesitemos. Toda esta información es almacenada en una base de datos local, MySQL o MariaDB.

En una arquitectura headless cortamos la cabeza de nuestro gestor: desacoplamos las funcionalidades de front-end y nuestro CMS ahora solamente se encargará de gestionar la información y entregarla por medio de un API (REST o recientemente GraphQL) o archivos estáticos hacia uno o más servicios y por qué no, poder integrarlo con una arquitectura de microservicios.

Ventajas

No todo es perfecto

Tech Stack

Y llegó la parte que a muchos de nosotros nos gusta más: elegir nuestro stack:

NextJS

Los caminos de la vida me han traido hacia React y como explicaba en un artículo anterior (TODO: Link al artículo anterior) la mejor alternativa para un proyecto e-commerce es adoptar el enfoque de Server Side Rendering, siendo NextJS la opción indiscutible:

  • La plantilla de NextJS Commerce nos da un punto de partida, aunque molesta un poco la dependencia a BigCommerce.
  • Optimización de imágenes con next/image, veremos si es tan bueno como gatsby-image.
  • SSR y SSG en un mismo proyecto sin mayor complicación.

Tailwind CSS

Typescript

Oye, ya me estoy complicando bastante con NextJS, por qué no hacerlo aún más divertido tipando nuestro JavaScript?

GraphQL

WordPress / WooCommerce

Ya lo conocemos, es fácilmente personalizable, PHP es bastante estable (y PHP 8 se ve MUY interesante), GraphQL lanzó la versión "estable" de su plugin para WordPress, creo que no hay mejor forma de ingresar al mundo headless de manera relativamente segura.

¿AWS o Vercel?

¿Vale la pena tanto esfuerzo?

Luego de 7 meses de lecturas, opiniones diversas, conferencias, documentación y más tutoriales, llegué a la conclusión que nadie tiene la razón, por lo tanto esa será la pregunta que trataré de contestarme a lo largo de las siguientes publicaciones.

Siguientes pasos

  1. Diseño de interfaz de usuario (en proceso) y mejorar la experiencia del usuario: hora de aplicar lo aprendido en el taller de UX que acabo de terminar.
  2. Organizar el trabajo por sprints de 1 semana.
  3. Get high and go dev