Como no trabajo allí, realmente no puedo comentar sobre la situación particular. Sin embargo, para muchas aplicaciones Rails de tamaño mediano, llega un momento en que los ingenieros y la gerencia necesitan tener una discusión seria sobre si el sistema se puede escalar o no. Yo diría que esto se reduce en gran medida a tres cuestiones:
- Muchos desarrolladores de Rails, al igual que muchos otros desarrolladores “back-end”, no entienden cómo funcionan realmente las bases de datos, porque Entity Framework, ActiveRecord y similares lo han hecho para que no tengan que hacerlo. Pero si un desarrollador no sabe cómo establecer un índice en una tabla, se encontrará con una limitación de rendimiento mucho más rápido que uno que no tenga miedo de los detalles sangrientos de la base de datos. En Rails, User.all.count y User.all.length son dos cosas muy diferentes, incluso si producen el mismo resultado. La codificación eficiente puede ocurrir en cualquier plataforma, y la codificación ineficiente puede ocurrir en cualquier plataforma; Rails parece tener más que su parte justa de este último.
- Así como ActiveRecord no hace mágicamente innecesario tener que saber cómo funcionan las consultas, tampoco resuelve problemas de escalado de la base de datos. Sharding, los clústeres MariaDB / Galera y una de las soluciones más populares actualmente, lanzar todo en RDS y dejar que Amazon se ocupe del escalado, son formas válidas de escalar una base de datos relacional, y todas ellas funcionan en Rails. Se necesita una gran cantidad de datos para que una base de datos supere a un solo servidor, y tan rápido como los conjuntos de datos crecen, las capacidades del servidor también lo hacen. Para bases de datos basadas en documentos, la escala de múltiples nodos es a menudo una funcionalidad central de la solución; Mongo / Cassandra / Couch con gusto escalará sin demasiada dificultad.
- Al final del día, todos estamos persiguiendo el rendimiento tipo C, y Ruby permite que un desarrollador vaya directamente con ruby.h y extensiones nativas. He escrito una serie de gemas extendidas de forma nativa, a veces porque no quería portar una base de código masiva a Ruby, pero a menudo porque ciertas cosas solo quieren ejecutarse en C. Por ejemplo, cualquier cosa que involucre CUDA.
Mirar la pregunta “¿cambiarán” inevitablemente trae otra pregunta: ¿a qué cambiarían? Cualquier persona que no tenga que cumplir con los requisitos de TI heredados es diferente a elegir C # MVC, por lo que está fuera si una tienda ya está en Rails. Nada en el mundo de PHP ofrece una ventaja de rendimiento suficiente para hacer que un cambio valga la pena, y muchos de los marcos de otros lenguajes son realmente más lentos. El nodo es una opción común, pero viene con sus propios dolores de cabeza configurados. A menudo uso Node junto con Rails para manejar pequeñas operaciones que no requieren el código más complejo que ofrece la pila completa de Rails y los conjuntos de gemas; No creo que recomiende planear una aplicación de esa manera, pero es una forma bastante fácil de resolver el problema de escalamiento de Rails, y parece ser una tendencia creciente para las empresas que necesitan cambiar, pero no quieren hacerlo por completo. volver a escribir.
- Cómo aprender de forma inteligente para convertirse en un desarrollador de pila completa
- ¿Cómo se obtiene un trabajo de ingeniería frontend en un equipo web de primera clase?
- Si solo está haciendo un sitio web informativo / educativo / hobby, ¿realmente necesita incluir su dirección en la política de privacidad?
- ¿Es posible ser un programador exitoso sin creatividad?
- ¿Cuál es la mejor manera de encontrar socios o cofundadores para una plataforma educativa?
