8 ms·

Play is the closest - but it's nowhere near the maturity of Rails. One good strategy that I see a lot of companies adopt is to write a services layer in Java/Sc

by karterk 14y ago

Play is the closest - but it's nowhere near the maturity of Rails. One good strategy that I see a lot of companies adopt is to write a services layer in Java/Scala and then keep the front-end Rails app part light weight. This way, you get the benefits of a robust, type-checked backend and the flexibility of Rails for the strictly web related stuff like asset pipelines etc. Of course, the downside is that you need to switch context between two languages. However, this has not bothered me in the past too much.

christiangenco 14y ago
Oh interesting. That would be quite nice, actually... Have you found Play to be significantly faster than Rails/worth the context switching?
ciniglio 14y ago
For this approach, how do you tie the two pieces together (e.g. the Java and Rails parts)? Do you have recommendations for where to start learning about building one system with multiple languages?
- scottschulthess 14y ago
  I believe OP is referring to a service-based architecture. Basically you have a front-end, written in rails, and a back-end, written in java. The two communicate using REST service calls. Personally I think for a lot of apps this approac has a lot more cons than pros. - everyone that wants to work on the app needs to know both ruby/rails and java/whatever else - multiple ways to handle deployment, continous integration, testing (different tools for java vs ruby). - have to run multiple apps constantly to be able to do end-to-end testing - harder to create full-stack integration tests - deployments between the apps are often coupled and thus require more planning - more up front API design work for the team. much harder to add new features that require API changes than ones that dont. - Automated end to end integration testing can be much harder to do with an app made up of multiple services than simply living inside on process and being able to have test code access both databases to seed data.
scottschulthess 14y ago
There are more downsides than "you need to switch the context between two languages" There are plenty of apps (i'd say the vast majority) where simply does not make sense to cut the codebase in half.

by karterk 14y ago

christiangenco 14y ago

Oh interesting. That would be quite nice, actually... Have you found Play to be significantly faster than Rails/worth the context switching?

ciniglio 14y ago

For this approach, how do you tie the two pieces together (e.g. the Java and Rails parts)? Do you have recommendations for where to start learning about building one system with multiple languages?

scottschulthess 14y ago
I believe OP is referring to a service-based architecture. Basically you have a front-end, written in rails, and a back-end, written in java. The two communicate using REST service calls. Personally I think for a lot of apps this approac has a lot more cons than pros. - everyone that wants to work on the app needs to know both ruby/rails and java/whatever else - multiple ways to handle deployment, continous integration, testing (different tools for java vs ruby). - have to run multiple apps constantly to be able to do end-to-end testing - harder to create full-stack integration tests - deployments between the apps are often coupled and thus require more planning - more up front API design work for the team. much harder to add new features that require API changes than ones that dont. - Automated end to end integration testing can be much harder to do with an app made up of multiple services than simply living inside on process and being able to have test code access both databases to seed data.

scottschulthess 14y ago

There are more downsides than "you need to switch the context between two languages" There are plenty of apps (i'd say the vast majority) where simply does not make sense to cut the codebase in half.