Zeitwerk es un cargador de código eficiente y seguro para hilos para Ruby. Mientras el proyecto siga las convenciones de nomenclatura, Zeitwerk puede encontrar los archivos correctos y cargarlos bajo demanda o de antemano, sin necesidad de usar require o require_dependency. Además, según ese artículo https://weblog.rubyonrails.org/2019/2/22/zeitwerk-integration-in-rails-6-beta-2/, podría proporcionar un pequeño aumento de rendimiento a la aplicación.
Hay algunos pasos que debo realizar para que funcione:
Cambiar el nombre de algunas clases para seguir la convención de nomenclatura de Rails. Por ejemplo, el archivo canonical_url.rb debería definir la clase CanonicalUrl en lugar de CanonicalURL. De manera similar, el archivo ondiff.rb debería definir la clase Onpdiff en lugar de ONPDiff. Una alternativa sería conectar un inflector personalizado al proyecto; sin embargo, creo que seguir la convención podría ser una mejor opción: GitHub - fxn/zeitwerk: Efficient and thread-safe code loader for Ruby · GitHub
Al igual que en el punto anterior, por convención, las validaciones personalizadas que residen en el directorio validations deben estar envueltas en el módulo Validations. Además, algunas validaciones heredan de EachValidator y deben ser accesibles sin espacio de nombres. Planeo moverlas a un directorio separado y agregarlas a las rutas de autocarga.
Eliminar todos los require_dependency y asegurarse de que el proyecto funcione correctamente.
Eliminar todos los require y asegurarse de que Discourse funcione correctamente.
Asegurarse de que todos los plugins puedan acceder a las dependencias requeridas. Aún no sé cómo lograrlo. Quiero primero hacer que Discourse funcione sin ningún plugin.
Por supuesto, aún quedan muchas incógnitas por resolver. Mantendré informados sobre el progreso; sin embargo, si están interesados en echar un vistazo, comencé a experimentar con esto aquí: Commits · KrisKotlarek/discourse · GitHub
Por favor, háganme saber si ven alguna desventaja al implementar Zeitwerk o si creen que me he olvidado de algo.
He avanzado un poco con Zeitwerk, aunque he cambiado mi enfoque. Mi plan original era modificar cada lugar donde Discourse no sigue la convención de nombres de archivos de Zeitwerk. Tras aplicar algunas correcciones, me di cuenta de que esto es solo la punta del iceberg y noté que, si seguía por ese camino, la solicitud de extracción (pull request) sería difícil de leer y de fusionar con confianza en master. Por ejemplo, todas las clases de trabajo ubicadas en directorios regulares deberían tener el espacio de nombres Regular, lo mismo ocurre con Onceoff y Scheduled.
Decidí dar un paso atrás y pensar en un enfoque más evolutivo que revolucionario.
Pensé que sería mejor introducir un Inflector personalizado que abarque todos los archivos que no siguen la convención de Zeitwerk. La mayor ventaja será que podremos desplegar ese pequeño cambio y, una vez que estemos satisfechos con Zeitwerk y no haya ninguna degradación del rendimiento, podremos comenzar a corregir la convención archivo por archivo en solicitudes de extracción razonablemente pequeñas.
Encontré algunos problemas que no podían resolverse con el Inflector personalizado, por lo que realicé correcciones adicionales para que funcionara.
La solicitud de extracción aún está en progreso, pero en esta etapa puedo ejecutar Discourse con Zeitwerk y los plugins predeterminados, ejecutar todas las pruebas y realizar las pruebas de rendimiento sin problemas.
Quería llegar primero a ese estado estable en el que todas las pruebas se superaran. Ahora puedo comenzar con confianza a eliminar todos los require_dependency uno por uno y también probar los plugins oficiales. Una vez que todo esté listo, compartiré con ustedes los resultados de las pruebas de rendimiento en esta publicación.
Para que los plugins funcionen, tuve que crear algunos pull requests pequeños adicionales. Una vez que se fusionen, creo que las pruebas en Discourse deberían pasar.
Podemos probar otra forma de realizar las pruebas de rendimiento. ¿Qué te parecería hacer más iteraciones, algo que se ejecute durante una hora? Además, en lugar de tomar el mejor resultado, compara el promedio de cada experimento. Eso podría dar números más consistentes. ¿Qué opinas?
En mis solicitudes de extracción para complementos, notarás que muchas correcciones se centran en la búsqueda en el espacio de nombres global.
Cambié código como
module ::Jobs
class TranslatorMigrateToAzurePortal < Jobs::Onceoff
por
module ::Jobs
class TranslatorMigrateToAzurePortal < ::Jobs::Onceoff
Una cosa me molestaba de esa solución: ¿por qué funcionaba antes de Zeitwerk? Esa pregunta, cuando algo funciona pero no debería, siempre es complicada
Zeitwerk es más estricto. Una vez que intenté cargar el código antes de corregirlo, se quejaba de que Jobs::Jobs::Onceoff no se podía encontrar.
Sam sugirió en la solicitud de extracción FIX: Use top-level namespace for base classes · discourse/discourse-prometheus-alert-receiver@ef9c238 · GitHub que, en lugar de usar < ::Jobs::Onceoff, podríamos simplemente usar < Onceoff, y tiene razón. Verifiqué que funciona igual sin el espacio de nombres. Estoy pensando que usar :: indica explícitamente que heredamos de una clase del núcleo de Discourse, pero podemos optar por cualquiera de las dos opciones.
Creo que cuando el código está tan cerca, esto se lee muy bien:
module ::Jobs
class TranslatorMigrateToAzurePortal < Onceoff
Si el código empieza a separarse, tiene más sentido ser explícito… por ejemplo:
module ::Jobs
[ 50 líneas omitidas]
class TranslatorMigrateToAzurePortal < ::Jobs::Onceoff
Dicho esto, estoy indeciso, así que me parece bien de cualquier manera. ::Jobs::Onceoff es lo suficientemente corto y mega explícito, así que podemos quedarnos con eso por ahora.
Me encantaría empezar a fusionar esto. @kris.kotlarek, ¿está ahora en un estado fusionable? El momento es bastante bueno porque acabamos de tener una beta.
@sam Creo que estamos listos. He rebaseado con la rama master más reciente y realicé un pequeño ajuste en Webauthn. Verifiqué tres cosas:
Ejecutar el servidor en local y hacer algunas pruebas para asegurar que funciona como se espera
Ejecutar las pruebas (specs)
Descargar todos los plugins oficiales y asegurar que las pruebas de los plugins estén pasando (primero necesitamos fusionar los ajustes para los plugins)
