Short story:
My company has a rails application as our product. As we add more functionality, we are thinking of building new small, self-contained rails applications rather than just chugging along with our single monolithic application that we have right now.
What is the best way to do this? Is it even recommended?
Long story:
My company, www.readMedia.com, specializes in press release distribution over the web and our product is a 60,000 line Ruby on rails application. We want to start adding some functionality that sort of has to do with existing functionality, but not really. It would use most of the same data, but the product could be sold separately to new clients, or as an add-on to old clients.
The easiest thing to do would be to simply build that functionality into our existing application. However, that has some drawbacks. As the application gets bigger and bigger, and we hire more programmers, the testing gets harder, the organization gets harder, deployment gets harder, the code gets messier, et cetera.
What we would like to do instead is to build new functionality as a separate rails application entirely. This has many advantages. Each application/functionality can be upgraded independently, turned on or off at will, have its own team of programmers who never have to worry about stepping on the feet of other teams, source control becomes easier, deployment is easier, et cetera.
The problem, to me, is that this seems to be technically really REALLY hard, if not impossible. It sounds wonderful in theory, but can (should) it even be done? Although the functionality of each application would be different, they would share most of the same data, such as our geographic table of zip codes and counties and our history of sent releases.
One thought is to use the same database for each application. This seems really tough. How would we keep the models in sync with each other, because things such as validation is very important? Another thought is to use multiple databases, one with the shared information, and another for each application to hold its own stuff. Again, very difficult. As far as I can tell, rails simply can't use multiple databases. I've found a plug-in or two that supposedly does this, but I'm not sure I would trust it.
Another thought is to have some API between the old system and the new applications that we are making. Although certainly possible, this seems like an extraordinary amount of work. How do we secure communication between applications? How do we share user accounts? Making an API would basically mean re-creating all of the existing functionality in an outward facing manner that can be called from another application. I don't really know how to do that, nor do I have any experience with that sort of thing.
Another thought is to synchronize the data occasionally between our applications. Have a background task that runs every night and updates each database in sync with each other. This is a nice solution, but it means that changes are propagated slowly, and syncing has historically been very difficult in the programming world.
As my final thought, I've been thinking about what 37 signals does. Their applications don't really interact at all. You have to login separately to each one, data isn't shared between them, they are basically separate products. In our situation we would like our products to be more tightly intertwined than the 37 signals ones. However, given that 37 signals doesn't do it, perhaps it's not possible? It's not what rails was designed to do? It's a bad idea?
Anyway, what do all of you think? Do we just keep growing and growing the main application? Do we force ourselves to create completely separate products?
If we can somehow segment functionality into different rails applications that still work together as a whole, what is the best way to do it? Has anybody tried? Does anybody have any experience with this? Please share any tools, plug-ins, or best practices that you think could help.
Thanks a lot!
