Localtower v2: Nunca es demasiado tarde
English version of this post here (EN)
Spanish version of this post here (ES)
French version of this post here (FR)
Génesis de la idea
En marzo de 2017, estaba enseñando Ruby y Rails a desarrolladores junior. La forma natural de aprender Rails es crear una aplicación desde cero, añadiendo modelos, controladores, vistas, etc. Un ejercicio simple para entender cómo se conectan las cosas.
Rails tiene herramientas fantásticas con migraciones de base de datos cuando se trata de crear modelos o migraciones. La API te permite gestionar el esquema de tu base de datos como un encanto.
Y con más de 12 años con Rails, todavía cometo errores muy a menudo.
La creación de una migración para añadir una nueva tabla es propensa a errores. Es fácil cometer errores o erratas en el archivo generado al añadir columnas. Siempre vuelvo a otras migraciones, copio la línea que se parece a lo que quiero, adapto los nombres y ejecuto rails db:migrate. Si tengo un error, vuelvo al archivo de migración, consulto la documentación de Rails si es necesario, lo modifico y ejecuto de nuevo db:migrate.
Quería algo más amigable: Una interfaz limpia con botones y menús desplegables para crear modelos y migraciones.
Así que creé la primera versión de Localtower como prueba de concepto en pocos días. Sorprendentemente, dos semanas después del lanzamiento, apareció en Ruby Weekly (número #341) y las descargas subieron a más de 38.870 descargas y 402 estrellas en Github. (las estadísticas están aquí en BestGems.org)
Fue suficiente para convencerme de mantener este proyecto vivo. No solo como una herramienta para hacer mejores migraciones, sino también como una herramienta de aprendizaje para desarrolladores junior para que entiendan todas las posibilidades que tienen con las migraciones.
El auge de las herramientas para desarrolladores
Las cosas han evolucionado mucho desde 2017 en términos de herramientas para desarrolladores. Aunque uso Rails todos los días y me encanta, no todo el mundo se siente cómodo programando cuando se trata de crear prototipos. Por eso las herramientas low-code o no-code se han vuelto populares. Por una buena razón:
Sus interfaces de usuario son realmente impresionantes.
Por nombrar algunas: Make, Zapier, Supabase, BuildShip, Bubble.
Por eso decidí reescribir completamente la interfaz de usuario de Localtower y proporcionar una mejor experiencia para los desarrolladores en cuanto a la gestión de bases de datos. La capacidad de iterar rápidamente en tu esquema SQL es clave para el prototipado e incluso más tarde cuando tu aplicación comienza a tener más de 10 tablas.
Diferencias entre v1 y v2
Todo cambió entre v1 y v2 respecto a la interfaz de usuario. Todos los componentes principales del backend son los mismos (con una pequeña refactorización) pero la interfaz es completamente nueva.
Toda la documentación está en el repositorio Github de Localtower: https://github.com/damln/localtower
Demo completa (2min)
Algunas capturas de pantalla
Restricciones técnicas con Rails Engine
Como Localtower es un Rails Engine, vive dentro de una aplicación Rails existente. No controlas la aplicación principal. Algunas personas pueden usar Localtower con Rails 5.2, Rails 6, Rails 7 o Rails 8. Esto significa que no puedes usar las últimas características de Rails como Turbo o Streams porque la aplicación principal podría estar usando una versión antigua de Rails. Lo más importante: el motor no puede establecer su propia versión de Rails. Estás completamente ligado a la versión de la aplicación Rails que aloja el motor.
Esto significa que terminé haciendo cosas extrañas. El pipeline de assets tenía que ser completamente javascript y no depender de sprockets o propshaft para ser a prueba de futuro. Y los componentes de backend necesitaban soportar varias versiones de Rails. El lado del backend fue más fácil de gestionar ya que solo uso la API de migración nativa.
ReactJS se unió a la conversación
¿Por qué React? No porque me guste. Pero su popularidad lo convierte en una gran opción para un simple proyecto de código abierto.
Crear migraciones y modelos consiste en añadir entradas a una tabla de forma limpia. Añadir una fila, cambiar una fila, selectores dinámicos, eliminar una fila, etc. Todas estas interacciones tenían que ser instantáneas. Así que la nueva interfaz de usuario está gestionada por ReactJS. Mi código JS es absolutamente malo. Necesito refactorizar algunas partes y reutilizar más componentes. Pero primero quiero recopilar comentarios para ver qué merece una evolución.
Como resultado de usar la API de migración nativa y ReactJS, logré que Localtower fuera compatible con Rails 5.2 hasta Rails 8.
Conclusión
Por un lado, soy un gran fan de tener código para crear prototipos y usar la línea de comandos todos los días. Pero por otro lado, me pregunto por qué nos quedamos atascados en este paradigma cuando se trata de Rails. Ya tenemos interfaces impresionantes para Sidekiq, SolidQueue (Mission Control), GoodJob, ActiveAdmin, RailsAdmin, y muchas otras herramientas que te ayudan a desarrollar y monitorear aplicaciones Rails. ¿Por qué no tener una para migraciones de base de datos?
Si quieres probarlo, te recomiendo leer el README.md en el repositorio de Github.
Si quieres hablar sobre esto y compartir comentarios e ideas, puedes encontrarme en X: https://x.com/damian_lnd
También puedes abrir un issue en Github aquí.