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.
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.
There are plenty of apps (i'd say the vast majority) where simply does not make sense to cut the codebase in half.
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.
Have you found Play to be significantly faster than Rails/worth the context switching?