De WordPress a un sitio estático

Nuevo año, nuevo sitio. Pero esta vez no solo he cambiado el diseño sino también el “alma”.

Se dice que los ingenieros tienden a complicar una solución por naturaleza, y esta no fue la excepción.

Este es el resumen del por qué decidí cambiar de tecnología.

¿Cómo era antes?

Mi sitio web funcionó por más de 6 años con WordPress, tuve la oportunidad de vivir la evolución de la plataforma. Desde que era un “sistema para blogs” hasta ser una herramienta que está detrás de muchas aplicaciones y que está en el 29% de todos los sitios web del mundo.

Tiempo antes de pensar en moverme de tecnología trabajé en mejorar mi stack. Usaba GitHub para la manejar los cambios el tema (Sage), las versiones de WordPress y los plugins (Bedrock).

Cada vez que hacía un cambio en tema, este era actualizado por medio de Deploybot, quien creaba un nuevo build y escribía los nuevos cambios a Mediatemple, mi proveedor de hosting.

Ya con pipepline de deployment funcional, ¿por qué cambiarlo?

Los inconvenientes de mi stack

Sincronización de datos

Siendo WordPress una aplicación dependiente de una base de datos, el estado de cada una de ellas era independiente y difícil de replicar*.

Si necesitaba hacer preview de nuevo contenido, podía hacerlo en ambiente de producción usando “preview” dentro de WordPress y al estar seguro publicarlo, fácil.

De igual forma con un cambio de código, hago el preview en mi local y luego hago un commit y se inicial el pipeline de Continuous Deployment.

Pero que pasaba cuando es un cambio de ambos, contenido y código. Debía hacer el proceso por separado y se volvía un va y ven por algo tan sencillo.

*Usaba plugins de pago para sincronizar las bases de datos, WP Migrate DB Pro

Replicar ambientes

Para replicar un ambiente necesitaba de un servidor en el cual debía tener PHP y MySQL, esto podría solucionarse con Docker, vi tutoriales y me parecieron muy complicados simplemente para poder crear un ambiente de desarrollo portable e independiente, además que necesitaba aprender una tecnología que no utilizo en mi día a día y veía el beneficio en principio.

Es pesado

Mi sitio es un blog, un sitio web con artículos que se muestran de forma distinta y ya. Por qué debo cargar toda una aplicación en PHP para mostrar contenido que no cambia de forma constante y que es texto e imágenes.

No estoy diciendo nada contra WordPress, simplemente que para lo que necesito es mucho.

Los requerimientos

Entonces, necesitaba una solución para que mi sitio fuera: fácil de sincronizar datos, de replicar y liviano.

Además de eso, quería usar en un proyecto nuevas propuestas de frameworks y herramientas que la comunidad tenía.

Separación de “concerns”

Mi modelo (contenido) debía estar separado de mi vista. Al ser así, podría modificar el contenido independientemente de donde este proviene.

Además tendría un single source of truth y así podría replicar mi sitio simplemente replicando el frontend (la vista).

Frontend en javascript

Uno de los trends y propuestas que me convencen es el concepto de “reactive programming”, y es tan simple como: la interfaz refleja el estado de la aplicación en todo momento.

Y javascript como lenguaje que corre en el ambos, el cliente y el servidor hacía más fácil el desarrollo.

Debe ser estático

Un artículo rara vez cambia después que lo publico y las publicaciones de mis experimentos son actualizados cuando tengo una nueva versión y esto no pasa tan a menudo, digamos 1 vez al mes.

Entonces no necesito tener una base de datos todo el tiempo, de la cual leo el contenido y dependo de, en cambio podría tener el contenido en simples html, al final es solo texto e imágenes.

Debe tener CI y CD

Para los nuevos Continuous Integration (test automáticos que aseguran que mi nuevo código no rompe nada) y Continuous Delivery (todo Pull Request que es merged en master, crea una nueva versión del sitio automáticamente), si aún te confunde puedes leer este artículo.

No me tengo que preocupar de arrastrar y pegar los archivos que cambio (como los viejos tiempos en WordPress) sino que esto lo hace una máquina por mi.

La propuesta

En el año estuve experimentando con diferentes herramientas, tecnologías, frameworks y librerías.

Y me decidí por las siguientes:

• Contentful - como manejador de contenidos
• Next.js - para manejar mi aplicación en react
• Styled components - para estilar mis components
• Travis - para CI & CD
• Now - como servicio de hosting

Mi nuevo CMS, Contentful

Contentful es un Content Delivery Service, con un API robusta y fácil de utilizar, entre las características que me hicieron decirme por ella están:

• Preview API, puedo configurar un API con los “drafts” simplemente con cambiar el url del API, así tengo en mi ambiente de desarrollo el contenido que “estará en el futuro” sin necesidad de migrar los datos a una nueva base de datos.
• Webhooks, puedo configurar a que servicio notifico cuando hay un nuevo contenido.
• CDN integrada, ya no tengo que pagar más por Cloudfront ni S3 pues en el precio del servicio ya está incluido.
• SaaS, al ser un servicio no me tengo que preocupar por renovar el hosting, o actualizar algún módulo (plugin), o problemas de seguridad
• Headless por defecto, a pesar que WordPress ya tiene un API, sigue siendo muy robusto para tenerlo como un API de contenidos.
• Tiene “custom fields”, los contenidos se “modelan” con campos (como en ACF) y existe una gran variedad de campos, si no existe, puedes crear campos personalizados.
• Cliente de javascript, si bien Contentful tiene un API, también tiene un cliente que hace aún más fácil la integración con el CDA, extrayendo la implementación a una interfaz simple de utilizar.

Mi aplicación en react, next.js

A pesar que existen muchos frameworks, boilerplates or starters para proyectos en react, next.js tenía básicamente todo lo que necesitaba para mi proyecto.

• Usa react, nextjs está hecho para React, y eso ya es un punto para mi, además tiene una comunidad muy sólida y mucha experiencia en proyectos Open Source.
• SSR, nextjs tiene por defecto Server Side Rending, entonces no me debo de preocupar por el SEO pues las páginas se generarán en el servidor
• Generador de sitios estáticos, un una simple configuración de tener una SPA, a una aplicación común con servidor, puedo crear una aplicación que no depende de un servidor, al final es solo texto e imágenes no?
• Agnóstico, nextjs tiene un footprint muy pequeño y si bien trata que utilices las herramientas creadas por ellos, no te ata a usarlas, y lo que trata es de ser una buena base para aplicaciones hechas en React.

Adiós SASS. Hola Styled Components

Utilizamos Styled Components en la nueva documentación para Typeform y nos encantó, tanto que el equipo de ingeniería está moviendo los proyectos de CSS Modules a Styled Components, las razones:

• Es CSS con super poderes, pues sigues utilizando la sintaxis de CSS con más opciones
• Ya no debes emparejar componente con estilo, pues el componente tiene los estilos en si.
• Es compatible con SSR, por lo mismo se puede crear Critical CSS en caso necesitemos optimizar, en mi caso solo necesitaba generar el CSS base para mejorar el performance de mi sitio web.
• Tiene una librería “à la SASS”, llamóada Polished, en la cual tienes muchas de las funcionalidades que nos gustan de SASS.

Hola travis, adiós Deploybot

Travis es una herramienta para CI y CD, a mi parecer mejor que cualquier otra que existe hasta ahora:

• Se integra de maravilla con GitHub, puedes configurar crear preview en PRs, o solo generar nuevos builds en ciertas ramas en tu repo por ejemplo.
• Configuras el comportamiento de tus deploys por medio de un archivo comprensible, .travis.yml .
• Tiene soporte no solo para proyectas en javascript, pero muchas más tecnologías.
• Es gratis en proyectos OS, y mi sitio web lo es.

Adiós (mt). Hola now

Now es de la misma compañía que Nextjs, y se llama Zeit. Zeit tiene para mi el mejor UX para developers en todos su proyectos.

• Puedes deployar prácticamente cualquier tipo de aplicación, en Docker, node or stático
• Va perfecto con Nextjs
• Tiene un CLI que está perfecto, desde hacer deploys como crear nuevas instancias de tu aplicación desde la consola
• Es gratis para proyectos pequeños y muy barato para proyectos medianos.

La conclusión

Ahora mi sitio web corre mucho más rápido, es más fácil de actualizar y más estable, pues solo son archivos html con css. Estoy feliz con el cambio y espero que esto resuelva algunas dudas del por qué pienso regresar a los conceptos básicos de la web.