Front End de Java y Rails Frontend
ruby-on-rails grails (6)
He usado pares similares para uno de mis proyectos, pero en lugar de RoR utilicé Python. No creo que haya una gran diferencia.
En general, no hay nada específico en este tipo de programación. Dos cosas importantes que debes tener en cuenta:
- buena modularidad;
- protocolo bien pensado entre RoR y Java.
Primero se trata de la descomposición de la funcionalidad exacta entre partes del sistema. Tenemos algunos problemas por no entender qué parte de un trabajo debe realizar Java y qué parte de Python. En general, debe unir todas las funciones que están cerca unas de otras, y las cosas que están lejos deben estar conectadas en muy pocos lugares. Supongo que conoces las reglas de una buena modularidad, pero en el caso de componer idiomas diferentes, esto debe pensarse con mucho más cuidado. También puede estar interesado en crear varios servicios distintos de Java (por ejemplo, uno para el almacenamiento en caché de la base de datos y otro para el resto) para poder combinarlos libremente o incluso utilizarlos en otros proyectos más adelante.
El segundo es acerca de la comunicación entre tus partes. Puedo ver dos formas de comunicación: a través de una base de datos y a través de un protocolo de red puro. Los primeros necesitan alguna comunicación de red de todos modos, por lo que utilizamos un protocolo de red puro, sin ninguna otra forma de conectar partes.
Hemos experimentado mucho con SOAP , pero generó cientos de errores: este protocolo está bastante bien para conectar servicios escritos en un idioma (id Java to Java), pero es terrible para conectar servicios en diferentes idiomas: las herramientas automáticas para generar WSDL dieron diferentes los resultados para Java y Python, y la creación manual del esquema fue difícil y laborioso.
Entonces solíamos descansar . Utiliza todas las funciones del protocolo HTTP, como los cuatro métodos HTTP principales (POST, GET, PUT, DELETE), códigos de error y muchas otras cosas, por lo que cubre casi todo lo que desee. La única restricción con REST es que no puede contener el estado, por lo que puede necesitar implementar su propio mecanismo de sesiones.
Si no está muy cómodo con REST y busca algún ejemplo real, vea Facebook Graph API y para implementar servicios REST en Java puede usar Restlets .
Tengo una startup que considera construir un backend Java y un frontend de Rails. El backend de Java se encargará de crear una capa de almacenamiento en caché para la base de datos y ofrecer otros servicios adicionales. El frontend de Rails será principalmente para crear las herramientas de monitoreo y aplicaciones web.
¿Qué startups / compañías usan este tipo de configuración? ¿Cuáles son algunos inconvenientes en términos de velocidad de desarrollo, implementación, escalabilidad e integración?
(Lo que sería útil para mí es la experiencia personal o estudios de caso informales. Me gustaría des-priorizar las respuestas que abordan alternativas como Grails o JRuby a menos que resulte ser una gran parte de la ecuación)
¡Gracias!
Le recomiendo encarecidamente que considere tener el frontend y el backend en la misma JVM por motivos de rendimiento.
Para Rails, JRuby puede ejecutar Rails, y puede tenerlo en un contenedor Java EE que proporciona una comunicación rápida entre los componentes.
Tener varias arquitecturas que no se ejecutan en el mismo proceso requiere que hagas una comunicación basada en la red, lo que lleva mucho más tiempo que simplemente pasar una referencia a un objeto (no espero que desees utilizar la memoria compartida).
Tal vez estoy diciendo lo obvio aquí, pero lo más importante aquí es el hecho real de que estás combinando dos tecnologías. No solo el desarrollo será más lento: Rails y todos los frameworks Java esperan tener una aplicación Ruby / Java completa, pero para los otros problemas que mencionas (implementación, escalabilidad, integración), las herramientas y soluciones existentes no funcionarán, o al menos no muy bien.
Si tiene una razón convincente para combinar los dos, siga adelante, pero espere pasar más tiempo con estos problemas que con una única solución tecnológica. Si no lo hace, elija Rails o Java.
Twitter.com supuestamente usa un backend Java y Rails para su interfaz web. Aquí hay algunos recursos:
http://www.radicalbehavior.com/5-question-interview-with-twitter-developer-alex-payne/
http://blog.adsdevshop.com/2008/05/02/twitter-is-not-abandoning-rails/
http://twitter.com/#!/ev/status/801530348
Más específicamente, usan Scala en el back-end (que compila el código de bytes de Java):
http://www.artima.com/scalazine/articles/twitter_on_scala.html
No creo que haya nada de malo en este enfoque. Sin embargo, admitirá dos plataformas / máquinas virtuales diferentes. He visto este tipo de situaciones como resultado de una especie de fractura de experiencia dentro de una organización. Y terminas pagando mucho para tener dos conjuntos de experiencia en casa.
Si le preocupa el problema de la segmentación de expertos, le sugiero que ejecute JRuby of Rails. Ahora es muy maduro y funciona mejor que Rails on Ruby 1.8.x.
Nunca he hecho ningún desarrollo de raíles, pero aquí están mis pensamientos. ¿Por qué no usar Grails? He realizado una buena cantidad de desarrollo de Grails y funciona bien para la creación rápida de prototipos. También ofrece toda la potencia de Java, Spring e Hibernate. En lugar de ocuparse de la comunicación entre dos tecnologías diferentes, podría aprovechar el hecho de que Grails usa Spring e Hibernate bajo las coberturas para lidiar con el almacenamiento en caché así como también con cualquier otro requisito que estas tecnologías admitan. Si tienes desarrolladores de Java, Grails no debería ser difícil de recoger. La historia del plugin de Grails es decente. Todos ellos están almacenados en un lugar central y son fáciles de obtener, pero la calidad varía según el autor del complemento. También debe recordar que, dado que Grails usa Groovy, que es sintácticamente similar a Java y se ejecuta en la JVM, es muy fácil usar el código de Java existente, incluida la multitud de bibliotecas de Java disponibles. No lo sé con certeza, pero supongo que hay muchas más librerías para usar con Java y allí con Grails están disponibles para el lenguaje Ruby y Rails. No puedo hacer una llamada de uso de recursos para ti, pero mi pregunta sería ¿cuántas personas tienes con experiencia en el diseño de sistemas Rails que usan Java en el back-end con todos los inconvenientes que irán junto con eso? Puede encontrar que no tiene a nadie que sea experto en la depuración cuando algo falla en la comunicación entre las dos tecnologías.
Hemos utilizado Ruby on Rails para front-end y Core-Java SOAP Api para back-end. Funcionó muy bien.
El problema principal no es con el rendimiento sino con la gente. Es muy difícil contratar a expertos en Ruby on Rails para todo, en su lugar contratan pocos o pueden moldear fácilmente para aprender la interfaz de usuario de Rails.
Como punto de vista de inicio, es la mejor estrategia. Muchos creen que ROR es mejor para las startups ... pero muy pocos lo sabían porque en la mayoría de las multinacionales usamos Java, por lo que existe la presión de aprender Rails y Code, o contratar muy pocos desarrolladores de ROR. Por lo tanto, en su lugar puede usar ROR para frontend (solo algunas personas lo hacen, o es fácil de aprender) y usar desarrolladores experimentados de Java para actualizaciones de bases de datos y lógica de negocios.