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.
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?
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
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.
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.
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.
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).
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.
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.
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.
En el año estuve experimentando con diferentes herramientas, tecnologías, frameworks y librerías.
Y me decidí por las siguientes:
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:
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.
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:
Travis es una herramienta para CI y CD, a mi parecer mejor que cualquier otra que existe hasta ahora:
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.
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.
📚
2 functions that made my components responsive at The practical dev.
From WordPress to static site—the Contentful way at Contentful's blog.
Coders Cut: The conversational article at Typeform's blog.
📹
The journey of a new interface at Frontend Connect.
Jepser Bernardino: Sitios web estáticos con WordPress y React at WordPress.tv.
Jepser Bernardino: Styled components ¿Por qué css en javascript? at WordPress.tv.