En el pasado, Psono.com funcionaba con Odoo v11. Odoo es un gran CMS, pero como tuvimos que aprender, las actualizaciones son difíciles. Especialmente su módulo de sitio web produjo muchos problemas durante nuestras pruebas. Odoo v11 alcanzará su fin de vida a finales de 2020, por lo que nos vimos obligados a encontrar una solución.
Pensamos en diferentes opciones, ya sea actualizar a Odoo v13 y migrar manualmente todo el contenido y personalizaciones nosotros mismos, contratar a alguien para que haga la migración por nosotros, o migrar completamente a un nuevo CMS. Hemos decidido migrar completamente a Psono.com y continuaremos usando v11 detrás de un firewall y lo migraremos más tarde (aún no hemos decidido).
Las razones detrás de esa decisión fueron:
- Solo tenemos una cantidad muy pequeña de contenido que necesitaríamos migrar para Psono.com. Principalmente algunas publicaciones del blog.
- Una migración a Odoo v13 reproduciría el mismo problema en dos años cuando v13 alcance su EOL, potencialmente con muchos más datos para migrar.
- No estábamos muy contentos con las capacidades de personalización de los sitios web de Odoo v11. Todo es extremadamente complejo con sus plantillas almacenadas en la base de datos.
- Los costos. Contratar a alguien para realizar la migración nos costaría al menos 5000 USD, potencialmente más.
- La comunidad de Odoo era muy activa, pero con el desarrollo en los últimos años de cambios de licencia y la migración de funcionalidades y complementos a soluciones de pago, poniendo todo detrás de un muro de pago, la comunidad está muerta.
- Psono.com es principalmente un sitio web estático con contenido estático. Si necesitáramos contenido dinámico, podríamos extraerlo con APIs.
El viaje
Después de tomar la decisión de migrar, tuvimos que decidir qué marco utilizar. Hay marcos clásicos como por ejemplo Hugo que usamos, pero su funcionalidad es limitada. Mientras buscábamos alternativas encontramos algunas soluciones en el mundo de node/react.
Quería escribir aquí "soluciones excelentes", pero no creo que nada en el estado actual roto del desarrollo frontend merezca ese título. ¿Roto preguntas? ¿Recuerdas los tiempos en que los desarrolladores podían crear un sitio web con un index.html y una etiqueta script para cargar jquery y podían comenzar a desarrollar sitios web? Ahora necesitas npm o yarn, necesitas entender package.json, scripts de webpack, marcos modernos como angular o react, que todos traen su propio cliente. JSX o typescript. Funcionalidades como la recarga en caliente no funcionan de manera confiable (archivo no monitoreado, algunas modificaciones necesitan un reinicio completo, o la recarga en caliente se activa demasiado pronto y tienes que actualizar manualmente de todos modos), así que terminas matando servidores de desarrollo y esperando minutos para que vuelvan a estar en funcionamiento (al menos en proyectos más grandes). ¡Echo de menos presionar F5 y tener todo allí sin problemas! No hablemos de un nuevo marco o herramienta al menos cada seis meses donde las herramientas antiguas son abandonadas a diario. Podría llenar páginas fácilmente despotricando sobre el estado actual del desarrollo frontend. En fin, volvamos al tema actual.
A falta de alternativas razonables, las mejores opciones (en el momento de escribir esto) serían next.js y gatsby. Al menos así las promocionaban algunos artículos. Ambas son igualmente populares si comparas estrellas o commits en Github. La única diferencia que pudimos notar durante una evaluación inicial es el requerimiento de un componente servidor para next.js, mientras que gatsby crea sitios estáticos (¡Por favor, no me maten si hay una opción para ejecutar next.js sin un servidor activo! :D)
Así que jugamos un poco con Gatsby y parecía estar bien. Como siguiente paso avanzamos y buscamos un tema. Gatsby es una herramienta "nueva", así que todos los temas que pudimos encontrar aún estaban en un estado muy básico. Treinta minutos y treinta dólares después, teníamos un tema visualmente atractivo que cubría al menos algunos de los componentes necesarios y comenzamos a modificarlo.
Hoy en día, como opción de hosting, puedes elegir entre múltiples proveedores, a saber: Firebase, netlify, Cloudflare, Vercel, simple GCP Cloud storage o AWS Cloudfront, servidores propios, contenedores docker ejecutándose en Kubernetes (¡tenía que mencionarlo!), ... (¿Recuerdas los viejos tiempos en que simplemente arrendabas un espacio web por $5 al mes con PHP y una base de datos MySQL? :D ... pero eso es para otro artículo...)
Luego de compararlos, leer algunas reseñas y revisar posibles combinaciones (como Cloudflare delante de Firebase), inicialmente probamos Cloudflare. Como grandes fans de su servicio, fue una elección natural, pero lamentablemente su utilidad wrangler tuvo problemas. Primero, siempre arrojaba un error y luego no pudimos autenticar ... Los errores iniciales desaparecieron al día siguiente (tal vez un nuevo bash hizo el truco), pero el problema de autenticación persistió. Creo que debí cometer algún error y renuncié después de un par de horas leyendo su documentación y probando diferentes soluciones.
Netlify fue otro candidato, pero o bien tienes que conectarlo a un proveedor git y dejar que ellos lo construyan (queríamos usar GitLab CI) o subir manualmente la salida de la compilación. Tal vez tienen una opción en algún lugar para cargar la salida de la compilación a través de una API, pero no pude encontrar una. Una alternativa habría sido un repositorio donde en realidad empujamos la salida de la compilación, pero eso parecía innecesariamente complejo... Otro problema para mí es su modelo de precios. Cobran por miembro (!!!) una cantidad bastante sustancial. Ten en cuenta que esto es para un sitio web estático. Declaraciones como "4× ancho de banda" traen malos recuerdos de los tiempos de "web hosting de uso justo" donde te expulsaban si usabas demasiado...
El cuarto servicio que probamos fue Firebase (que como beneficio es gratuito para nuestro ancho de banda y solicitudes objetivo) y todo funcionó desde el principio. Sus capacidades de redirección son un poco limitadas, por lo que mapear URLs antiguas a más bonitas se volvió un poco tedioso, pero después de un par de reglas de redirección todo estaba funcionando. Sus precios parecen razonables y se te cobra por recursos de servidor. Debes mantenerte alejado de todos sus servicios adicionales para evitar el bloqueo de proveedor, pero solo necesitábamos hosting.
También comprobamos brevemente vercel, pero su requisito de iniciar sesión con una cuenta de Github y luego un permiso con "Actuar en mi nombre" me desconcertó incluso antes de registrarme.
El blog fue el más difícil de migrar. Terminamos copiando todo el contenido manualmente. Eso no es algo que deberías hacer con un blog más grande, pero nuestro blog solo tenía quince publicaciones. Gatsby soporta múltiples mecanismos, pero queríamos algo simple que alguien sin formación técnica pudiera crear nuevas publicaciones en el blog. Decidimos usar markdown y como tal tuvimos que aprender a instruir a Gatsby para que leyera páginas markdown. El mecanismo real nos tomó aproximadamente medio día con todo el manejo de imágenes. Un bonito tema para el blog y las imágenes otro medio día.
Después de migrar todo el contenido y modificar fuertemente el tema, automatizamos nuestra implementación con Gitlab CI, así que un simple push dispararía nuestra pipeline de construcción y desplegaría todo en Firebase.
¿Por qué Gitlab y no Github? Github lleva la delantera por razones históricas. Actualmente tienen al menos el 80% de todos los desarrolladores y proyectos. Por otro lado, Gitlab ofrece características. Por eso en el pasado decidimos ir con Gitlab, ya que no hubo desarrollo real de características en Github durante años. Esto ha cambiado dramáticamente desde que Microsoft compró Github y Github Actions son un hito, pero Github aún tiene un largo camino por recorrer si quieren competir con Gitlab. Así que para nosotros que alojamos todos nuestros proyectos en Gitlab, fue una elección natural usarlo también para este proyecto.
La conclusión
Y aquí es donde estamos ahora:
- Gatsby como CMS
- Tema comercial
- Blog impulsado por markdown
- Gitlab CI para implementaciones automatizadas
- Hosting en Firebase
Estamos bastante contentos con este resultado y el nuevo sitio web se ve mucho mejor!
