As your business grows bigger, you just can’t stop adding new models/controllers to your original rails application – resulting in a messy, unmaintainable and difficult to deploy monolithic application. Its time to refactor. This talk will share our experience, results and best practices in splitting a single rails “application-system” into 30 independently maintainable yet interconnected applications.
After two and a half years of development (starting in pre-Rails 1.0 days!), our live-trainer English learning system now supported multiple roles (learner/trainer/trainer supervisor/sales/materials creation/support/etc) and an exhaustive list of features to support our complex business processes. We set ourselves a year-long goal of splitting this monolithic system into small cooperating applications that could be developed independently by individual developers. At the same time, we could not lose the usability cohesiveness and data-interdependence that defined the power of our system.
Through numerous iterations, many mistakes and a bit of pure-luck we developed an optimized process for the refactor and best practices for making 30 independent rails apps behave as one. The results: lower development time, greater stability and scalability and much higher developer happiness.
We’ll talk about specific code, measurements, pitfalls, plugins, process and best practices to answer questions such as:
How to know where to split single applications into many. How to measure the result.
How the applications should interact with each other. How to reduce administration and DRY configuration applications.
How to share data among applications.
How to DRY for common logic.
How to make a consistent user experience.
How to interact with non-Ruby technology; in our case Erlang, FreeSWITCH (VoIP) and Flex