¿Cuáles son los límites de ruby ​​en los rieles?

Question

Tengo un recuerdo de hablar con personas que hasta ahora han usado Ruby on Rails y luego tuvieron que abandonarlo cuando alcanzaron los límites, o descubrieron que, en última instancia, era demasiado rígido. Olvidé los detalles pero puede haber tenido que ver con el uso de más de una base de datos.

Así que lo que me gustaría saber es qué funciones/requisitos quedan fuera de Ruby on Rails, o al menos requiere tales contorsiones que es mejor usar otro marco más flexible, aunque es posible que deba perder algo elegancia o escribir un código repetitivo.

Answer 1

Los rieles (no ruby ​​en sí) se enorgullecen de ser "Software Opinionated".

Lo que esto significa en la práctica es que los autores de los rieles tienen en mente una cierta audiencia objetivo (ellos mismos básicamente) y apuntan los rieles específicamente a eso. Si la función X no es necesaria para esa audiencia objetivo, no se agrega.

De la parte superior de mi cabeza, cosas que rieles explícitamente no soporta que la gente puede preocuparse por:

1. claves externas de las bases de datos
2. Las conexiones a múltiples del DB a la vez
3. servicios web SOAP (desde los rieles 2.0)
4. Las conexiones a múltiples bases de datos servidores a la vez

Dicho esto, es muy fácil de extender los carriles con los plugins, y hay plugins que añaden toda la funcionalidad por encima de los carriles, y mucho más, así que realmente no los consideraría como límites.

La única otra advertencia es que los rieles son construidos en torno a la idea de crear aplicaciones web CRUD utilizando MVC. Si intenta hacer algo que NO es una aplicación web CRUD (como Twitter, que en realidad es un sistema de mensajería, o si está loco y quiere usar un modelo como formularios web ASP.NET), entonces también encontrará problemas. En este caso, es mejor que no uses rieles, ya que esencialmente estás tratando de construir un bote con partes de bicicleta.

Con toda probabilidad, los problemas que se ejecutará en que no sólo pueden ser fijados con un plug-in rápido o un día o 2 de codificación son todos los problemas inherentes con el subyacente de tiempo de ejecución C Rubí (pérdidas de memoria, hilos verdes, basura rendimiento, etc.).

Answer 2

Ruby on Rails no es compatible con las confirmaciones de dos fases, lo que puede ser necesario si la aplicación respaldada por la base de datos necesita garantizar consistencia inmediata Y debe usar dos o más esquemas de base de datos.

Para muchas aplicaciones web, me atrevo a aventurar que este no es un caso de uso común. Uno perfectamente puede soportar la coherencia eventual con dos o más bases de datos. O uno podría soportar la consistencia inmediata con un esquema de base de datos. El primer caso es un gran problema si tu aplicación tiene que admitir una cantidad mondo de transacciones (ten en cuenta el término técnico :). El último caso es más típico, y Rails lo hace bien.

Francamente, no me preocuparían por los límites para usar Ruby on Rails (o cualquier marco) hasta que alcance problemas reales de escalabilidad. Cree una asesina aplicación primero y preocúpese por la escalabilidad.

ACLARACIÓN: Estoy pensando en cosas que Rails tendría dificultades para soportar porque podría requerir un cambio fundamental en su arquitectura. Seré generoso e incluiré algunas cosas que forman parte del ecosistema de gemas/complementos, como la aplicación de claves foráneas o los servicios SOAP.

Por confirmaciones en dos fases, me refiero a intentar hacer dos confirmaciones a servidores físicamente distintos dentro de un contexto transaccional.

Caso de uso n.º 1 para una confirmación en dos fases: ha agrupado su base de datos para que tenga 2 o más servidores de bases de datos y su esquema se distribuya en ambos servidores. Es posible que desee comprometerse con ambos servidores, porque desea permitir que ActiveRecord piense en hacer un "mapa de clave externa" que atraviese los diferentes servidores.

Caso de uso n.º 2 para una confirmación en dos fases: está intentando implementar una solución de mensajería (lo siento, soy desarrollador J2EE por día). El productor del mensaje se compromete con el intermediario de mensajería (un servidor) y con la base de datos (un servidor diferente).

Answer 3

La respuesta de Orion es correcta. Hay pocos límites estrictos para AR/Rails: implementación en Windows, conectores AR que no se usan con frecuencia, p. Firebird,), pero incluso las cosas que mencionó, múltiples bases de datos y servidores de bases de datos, hay gemas y complementos que se ocupan de los heredados, fragmentados y otros motivos.

La limitación real es cómo el tiempo que consume que es mantener en la parte superior de todas las cosas que los carriles desarrolladores están trabajando, y la investigación de temas específicos, dada la cantidad de blogs, y la cantidad de volumen lista de correo existen.

Answer 4

También se encontró una buena discusión sobre el limits of ActiveRecord.

Answer 5

Creo que hay una mayor “meta-pregunta” aquí, que podrían ser respondidas y que es “¿Cuándo está bien apoyarse en las bibliotecas externas para acelerar el tiempo de desarrollo?”

bibliotecas

de terceros son a menudo excelente y puede reducir drásticamente el tiempo de desarrollo; sin embargo, hay un problema importante, Joel Spolsky lo llama "la ley de las abstracciones con fugas". Si lo busca en Google, su publicación aparecerá primero. Básicamente, esto significa que la compensación en el tiempo de desarrollo significa que no tiene idea de lo que sucede debajo de las coberturas. Entonces, cuando algo se rompe, estás completamente atascado y tienes métodos de depuración muy limitados. Esto también significa que si aciertas una de las funciones que simplemente no están soportadas en RAILS, que realmente necesitas, no tendrás el siguiente paso, excepto escribir la función tú mismo, si tienes suerte. Muchas bibliotecas pueden hacer esto difícil de hacer.

Nos hemos quemado mucho en mi tienda de desarrollo por este problema. Nuestras soluciones funcionaron bien bajo carga normal, pero descubrimos que las bibliotecas de suscripción de terceros que estábamos utilizando simplemente no podían soportar el tipo de carga que experimentamos una vez que nuestro sitio comenzó a tener una gran cantidad de usuarios simultáneos. Esto nos pone en un lugar muy difícil; esencialmente tenemos que reescribir todo el servicio de suscripción nosotros mismos, con el rendimiento en mente. Hacer esto significa que hemos perdido todo el tiempo que pasamos usando la biblioteca.

Las bibliotecas de terceros pueden ser excelentes para aplicaciones de tamaño pequeño a mediano; pueden reducir drásticamente el tiempo de desarrollo y ocultar las complejidades que no son necesarias para tratar en las primeras etapas de desarrollo. Sin embargo, eventualmente lo alcanzarán y probablemente tendrá que reescribir o rediseñar su solución para superar la "ley de las ausencias con fugas"

Answer 6

Ruby no tiene una funcionalidad como IsPostBack en ASP.Net