Por qué tu startup debería adoptar Ruby on Rails
En una época donde las startups digitales crecen cada vez más rápido y la demanda de personal de TI supera cada vez más a la oferta, un equipo pequeño de emprendedores puede ser capaz de competir contra productos de grandes empresas, y lo más emocionante es que tienen a la mano todas las herramientas para hacerlo realidad.
Desde Scrum como marco de trabajo para el desarrollo de productos, hasta Heroku como plataforma de despliegue de aplicaciones web, muchos productos, servicios y frameworks están diseñados para ayudar a los negocios pequeños a prosperar y a escalar desde cero.
Entonces, ¿cuáles son los problemas más comunes que tiene una startup pequeña y joven?
Algunos de ellos son:
- Presupuesto limitado
- Negocio poco definido
- Falta de experiencia administrando el negocio
- Mala estrategia de marketing
- No saber hacia dónde pivotear el negocio
Los pilares de Ruby on Rails expuestos en The Rails Doctrine pretenden ayudar a las startups a resolver los problemas de presupuesto, velocidad y definición de negocio mientras hacen felices a los programadores, es decir, es una herramienta más (y creo que la más importante) para la implementación de un producto digital.
Pero, ¿cómo nos ayudan a resolver estos problemas?
La doctrina
Cuando hablamos de “la doctrina” de Ruby on Rails nos referimos a los 9 pilares que sostienen la filosofía que guía el camino hacia un mejor framework y en parte, un mejor estado del arte para el desarrollo de aplicaciones web. Algunos de sus principios son:
Convención sobre configuración
Algunas herramientas open source están diseñadas por expertos y para expertos, pero ¿qué hay de los que sólo quieren empezar y ya?
Ruby on Rails propone una serie de herramientas y convenciones que en conjunto, si se siguen al pié de la letra pueden funcionar a la perfección.
Claro, aún así es posible cambiar algo si lo deseas, pero la belleza está en tener algo que funcione desde el desempaque, sin configuración.
Valora los sistemas integrales
Una punto en contra que escucho constantemente ser resaltado con respecto a Ruby on Rails es que es monolítico y nada escalable.
Es curioso porque dentro de sus principios, ser monolítico es algo bueno ya que significa que puedes:
- Integrar front-end y back-end developers en el mismo equipo
- Tener resuelta la comunicación entre front-end y back-end
- Mantener una sola base de código
Y recordemos que monolítico no necesariamente significa desorganizado ni revuelto, ya que podemos mantener una clara separación de responsabilidades haciendo el uso de las convenciones ya establecidas.
El menú es omakase
Por más único que sea nuestro producto, los ingenieros solemos enfrentar el mismo conjunto de problemas todo el tiempo, ya sea traducir textos, autenticar usuarios, manejo de ruteo dinámico, persistencia, búsqueda de datos, etc.
Ruby on Rails ofrece soluciones para estos y otros problemas del desarrollo de aplicaciones web, algunos de los más notables son:
- ORM (Active Record)
- Internacionalización (i18n)
- Ver, guardar y editar texto enriquecido (Action Text)
- Suite de pruebas (Minitest)
- Websockets (Action Cable)
- …y muchos más
Y cuando la solución no está integrada al framework aún, probablemente encontremos gemas que nos permitan hacerlo mientras la comunidad define un estándar y así poder ofrecernos la mejor herramienta posible para ese problema.
Existen también otros pilares importantes que forman la filosofía de Ruby on Rails y recomiendo leerlo a detalle en The Rails Doctrine de David Heinemeier Hansson.
El lado oscuro
Podría escribir mucho más sobre por qué es bueno usar Ruby on Rails, pero creo que también es importante conocer su lado oscuro y saber qué problemas no debe (ni quiere) solucionar.
Aplicaciones pesadas del lado del cliente
Las aplicaciones que no necesiten utilizar un ORM y que sólo necesiten consumir datos ya existentes, presentar y ocasionalmente hacer búsquedas sencillas sobre esos datos, no son del dominio de Ruby on Rails, y hacerlo significaría desperdiciar la cualidad más fuerte que tiene (Activerecord) y depender completamente de la más débil (Reactividad del lado del cliente).
Páginas web estáticas
Usar Ruby on Rails para crear páginas web estáticas o con pocos datos dinámicos sería como matar a una mosca con una escopeta.
Esto se puede solucionar con un CMS ya que está diseñado para eso, como Wordpress o Laravel Voyager.
Aplicaciones con alta concurrencia o alta demanda
Cuando una aplicación depende de su capacidad para ejecutar varios procesos concurrentes o soportar muchas solicitudes en un rango de tiempo muy corto, Ruby puede ser muy lento a comparación de otros lenguajes de programación.
Pero ¿realmente ese es el caso de la mayoría de las startups?
Cuando pensamos en escalar debemos ser cuidadosos en no caer en la ambición. Anthony Figeroa explica en su artículo Ruby doesn’t scale cómo podemos evitar el over-engineering y qué preguntas deberíamos plantearnos para mejorar nuestra aplicación sin culpar al desempeño del lenguaje.
“La realidad está hecha de círculos, pero todo lo que vemos son líneas rectas”
— Peter M. Senge
Aunque es una realidad que cada proyecto de software es diferente y único, muchos problemas en el desarrollo de software se han mantenido por muchos años.
Ruby on Rails pretende dar a los programadores una serie de soluciones integrales que aceleran el desarrollo de aplicaciones web, permitiéndoles ser más productivos y así poder enfocarse en resolver problemas de negocio.
Al haber creado uno de los frameworks más populares por más de 15 años, el equipo de desarrollo de Ruby on Rails ha tomado decisiones controversiales y ha impulsando fuertes ideales que los ha llevado a tener fieles seguidores y enemigos.
Ahora, ¿qué quieren estos enemigos?
La oposición
Durante mi trayecto como Ingeniero de Software y defensor de los ideales de la doctrina de Rails, he escuchado muchas preocupaciones sobre el conjunto de soluciones que proponen.
Estos son algunos ejemplos de sus preocupaciones, y lo que suelo responder:
Ruby on Rails no escala
¿Por qué necesitamos escalar ahora?
¿Hasta qué punto del futuro podemos seguir usando Rails?
Basecamp ha escalado usando Ruby on Rails, ¿por qué nosotros no podemos?
Tiene demasiada magia
Si magia significa que ya está resuelto, que así sea.
Creo que la magia nos ayudará más que perjudicarnos, sólo debemos asegurarnos de seguir las convenciones.
¿Un monolito? Mejor separémoslo en micro-servicios
Creo que tener un monolito no es algo malo.
Recuerda el principio: “valora los sistemas integrales”.
Sólo mira esos microsegundos, Ruby es muy lento
Bueno, si, ¿pero de verdad nos importa ahora?
Los cuellos de botella probablemente estén en las consultas, no en la velocidad de Ruby.
Y la más absurda de todas:
Ahí está la evidencia: Twitter dejó de usar Ruby on Rails
¡Por supuesto que lo hicieron!
¡Cuándo ya tenían millones de usuarios!
¡Cuándo tuvieron los recursos para hacerlo!
Un último consejo
Recordemos que Ruby on Rails fue creado pensando en la felicidad del programador, pero ¿qué pasa si tu equipo no quiere usar Ruby on Rails?
Es muy simple, no los obligues.
Confía en tu equipo para encontrar una herramienta adecuada para resolver el problema y que últimamente, los haga felices.
