DEV Community

Cover image for Ruby on Rails está muerto, fin.
Paul Marclay
Paul Marclay

Posted on

Ruby on Rails está muerto, fin.

No, es broma, ni cerca de estar muerto, a pesar de que todos los años aparece alguien sensacionalista matando a Ruby, Rails, PHP y otros lenguajes o frameworks.

Me encanta ROR, no es mi lenguaje materno, pero casi.

Cada vez que tengo una idea, la pienso en Ruby, en Ruby on Rails, me resulta mucho más fácil, tranquilamente se puede hacer un MVP en un día, si uno sabe a lo que quiere llegar.

Usando ROR, he trabajado en proyectos pequeños y grandes, algunos demasiado grandes, pero Rails hace que se sienta natural cada movimiento que das.

Ruby y Rails llevan al extremo el paradigma de "Convention Over Configuration" hasta el punto de que pensar saltarselo suene a blasfemia.

Todo hermoso, pero se acerca un problema.

Al pensar en hacer todo lo que conlleva a un proyecto utilizando sólo Rails, podemos pecar de integridad, y es lo que me pasó.
¿Qué quiero decir con eso?, que estamos utilizando un framework y sus buenas prácticas, pero las buenas prácticas deben organizarnos, no limitarnos.

Por ejemplo, me ha pasado tener que hacer consultas SQL complejas y, para no ser hereje, obviamente las hacía utilizando las buenas prácticas y modelos de ActiveRecord, a veces resultando queries costosas, difíciles de digerir para SQL mismo, ah, pero yo usaba buenas prácticas del framework.

Según mis pensamientos, nada debía tocar la base de datos si no era a través de un modelo de datos, su "updated_at" debía reflejar la fecha de última actualización de lo que se tocara, y ni hablar de que algo externo al proyecto accediera a ella!.

¿A dónde quería llegar con todo esto?, justo a este punto, un framework, por más poderoso, grande y versátil que sea, no deja de ser eso, un framework, un marco de trabajo, no restrictivo, si organizativo.

Utilizar un framework no quiere decir que tenemos que estrictamente limitarnos a sus buenas prácticas (ya veo un aluvión de comentarios de fanáticos de las buenas prácticas), simplemente debemos utilizarlas siempre y cuando nos sea posible, tomar lo que necesitemos y para el resto, usar nuestro ingenio de desarrolladores.

Este último tiempo trabajando con scrapers para obtener precios de productos en RantiQ, indexando noticias y menciones a marcas, organizaciones y personas en Dolem Labs, etc.; decidí romper con el paradigma que tenía casi impreso en mi hardware, a pesar de haber realizado las tareas con mi framework preferido, decidí darle una oportunidad a otros métodos, otros lenguajes incluso.

Ahora los crawlers corren sobre Python y sin un framework de guía, al menos no un framework de verdad, organizo mis propios modelos de datos cuando lo necesito, corro queries costosas que hacen "cosas locas" cuando lo necesito, analizando miles de páginas web por día y una vez más rompiendo mis estándares, no en un solo lenguaje, no todo bajo la tutela de un framework.

Y si, los scripts python tocan la base de datos, insertan miles de registros, actualizan otros cientos e indexan información para que a Rails le resulte más sencillo hacer su trabajo.

Y si, las cosas van mejor, no quiero entrar en el tema de Monolito vs Micro Servicios, ya está muy gastado. Vas a ver que al cargar un script Python (no porque sea Python, es porque no hay un framework) para realizar la tarea de scrapeo, sin necesidad de cargar todo un framework para una simple tarea, todo fluyó mucho más rápido, con mayor performance a la hora de hacer SQL queries libremente. También para el front fue todo más fácil y barato, ya que algunos scripts "pre mastican" la información y la dejan lista para consumir.

¿Hay que tener cuidado?, si, hay que tener cuidado, hay que conocer el framework como para no corromper datos y que después todo explote cuando se lo quiera consumir.

Ahora tengo tablas de las que Ruby on Rails no está enterado de que existen, tablas que se utilizan para hacer procesos costosos de indexación, ROR no necesita saber de eso, y ya no me siento culpable :)

En fin, no estoy diciendo que hagan cochinadas, estoy diciendo que al igual que Scrum es un marco de trabajo en el cual debemos basarnos para hacer un desarrollo de manera ágil, no es algo que nos limite para nada, las ceremonias que tiene (muchas para mi gusto) no suelen ser obligatorias, uno va tomando lo que necesita para que el proyecto fluya.

Volviendo al código, hay cosas que pueden ser mucho más performantes en otros lenguajes y/o frameworks que el que estás usando de base, vale la pena evaluarlo y sacarse la duda.

¿Es siempre recomendable hacer esto?
No, en general es recomendable atenerse a las buenas prácticas del lenguaje/framework que estés usando, más si es una startup en sus primeros pasos. Puede ser muy costoso mantener un proyecto con diferentes lenguajes y frameworks, sin mencionar el conocimiento de la lógica de ejecución de los mismos, y más aún, si hay scripts corriendo en diferentes servidores, puede llegar a ser un dolor de cabeza.

Y como para cerrar, experimenten, no se cierren a una sola manera de hacer las cosas.

Un saludo.

Paul.

Top comments (0)