Cuando nuestro cofundador e ingeniero Dmitriy Zaporozhets decidió construir GitLab, eligió hacerlo con Ruby on Rails, a pesar de trabajar principalmente en PHP en ese momento. GitHub, una fuente de inspiración para GitLab, también se basaba en Rails, por lo que era una elección lógica teniendo en cuenta su interés en el framework. El director general de GitLab, Sid Sijbrandij, cree que su cofundador hizo una buena elección:
«Ha funcionado muy bien porque el ecosistema de Ruby on Rails permite dar forma a una gran cantidad de funcionalidades con una gran calidad», explicó. «Si miras GitLab, tiene una enorme cantidad de funcionalidad. El desarrollo de software es muy complejo y para ayudarlo necesitamos mucha funcionalidad y Ruby on Rails es una forma de hacerlo. Debido a que hay todas estas mejores prácticas que están en su camino feliz, es también una manera de mantener el código consistente cuando se envía algo como GitLab. Estás guiado para hacer lo correcto».
Dependiendo de gemas útiles
Las gemas de Ruby juegan un papel integral en la construcción de GitLab, con la carga de más de mil gemas no únicas, según Sid. Calificando el framework Ruby on Rails de «muy opinable», cree que es un entorno fuerte en el que construir una aplicación compleja como GitLab.
«Hay un gran ecosistema a su alrededor con gemas que pueden hacer suposiciones sobre cómo estás haciendo las cosas y en ese sentido, creo que el ecosistema Ruby on Rails sigue sin par», dice. «Si miras nuestro Gemfile, te da una indicación de lo grande que es la torre de dependencias sobre la que podemos construir. ¡Ruby on Rails tiene unos hombros increíbles sobre los que apoyarse y habría sido mucho más lento desarrollar GitLab en cualquier otro framework.»
Superando retos
Todo esto no quiere decir que no haya habido retos en la construcción de GitLab con Ruby on Rails. El rendimiento ha sido un problema que nuestros desarrolladores han mejorado de varias maneras, incluyendo la reescritura de código en Go y el uso del framework Vue. Este último se está utilizando para reescribir las páginas de acceso frecuente, como las incidencias y las solicitudes de fusión, para que se carguen más rápido, mejorando la experiencia del usuario.
Go se está utilizando para abordar otros problemas que afectan a los tiempos de carga y para reducir el uso de la memoria.
«Ruby fue optimizado para el desarrollador, no para ejecutarlo en producción», dice Sid. «Para las cosas que se golpean mucho y tienen que ser muy performantes o que, por ejemplo, tienen que esperar mucho tiempo en una IO del sistema, reescribimos esas en Go … Todavía estamos tratando de hacer que GitLab use menos memoria. Por lo tanto, tendremos que habilitar el multithreading. Cuando desarrollamos GitLab eso no era común en el ecosistema de Ruby on Rails. Ahora es más común, pero debido a que ahora tenemos tanto código y tantas dependencias, va a ser un camino más largo para nosotros llegar allí. Esto debería ayudar; no lo hará increíblemente rápido, pero al menos utilizará menos memoria».
Añadir Go a la caja de herramientas de GitLab llevó a la creación de un servicio separado llamado Gitaly, que gestiona todas las peticiones de Git.
Construyendo sobre la misión de GitLab
El estilo organizado y estructurado del marco de trabajo de Ruby on Rails se ajusta a nuestra misión principal. Como Rails está racionalizado, cualquiera puede entrar en GitLab y participar, lo que lo hizo especialmente atractivo para Sid desde el principio.
«Nuestra misión es que todo el mundo pueda contribuir», explica. «Como Ruby on Rails es realmente opinable en cuanto a qué piezas van donde, es mucho más fácil para los nuevos desarrolladores entrar en el código base, porque sabes dónde ha puesto la gente las cosas. Por ejemplo, en cada cocina en la que entras, nunca sabes dónde están los cuchillos y los platos. Pero con Ruby on Rails, entras en la cocina y siempre está en el mismo lugar, y queremos seguir así.
En cada cocina en la que entras, nunca sabes dónde están los cuchillos y los platos. Pero con Ruby on Rails, entras en la cocina y siempre está en el mismo sitio, y queremos ceñirnos a eso.
«Me animé mucho cuando abrí el proyecto y lo vi por primera vez un año después de que Dmitriy lo empezara. Lo abrí y es Rails idiomático. Ha seguido todos los principios. No trató de experimentar con algún tipo de moda que le interesaba. Lo convirtió en una aplicación de producción. Dmitriy revisó cuidadosamente todas las contribuciones para asegurarse de que se ciñeran a esas convenciones, y eso sigue siendo así. Creo que tenemos un código base muy bueno que permite a otras personas construir sobre él. Uno de nuestros subvalores es el de las soluciones aburridas: no hacer nada extravagante. Esto es para que otros puedan construir encima. Creo que lo hemos hecho muy bien… y estamos muy agradecidos de que Ruby haya sido un ecosistema tan estable para que podamos construir sobre él.»
Imagen de portada de Elvir K en Unsplash
Deja una respuesta