Break Rails Project Into Multiple Projects For Better Performance And Cost Saving
It is inevitable that over time your project codebase explodes and start worrying about the memory footprint and performance. The same happened with us. We started with a Rails project and kept on adding features to it instead of making micro-services. After a couple of years, we had a big project which has a lot of background workers and hundreds of APIs. We wanted to reduce the memory footprint to improve performance and to reduce the EC2 instance size.
There are numerous challenges in breaking a big project into multiple:
- Reorganizing the code. Can not be avoided.
- Maintaining multiple projects and repositories.
- Changes in deployment scripts
Upsides of breaking the project will definitely make the effort look smaller
- Smaller memory footprint
- Different projects can be scaled independently
- Cost-saving on the cloud infrastructure
Things to do
- Identify the parts of the code which can be separated out.
- Move the common models to Rails plugins. Better to use namespaces in the models so that you know, which model is in which plugin.
- Identify the common code which is required in more than one project. Move this code to a gem or more than one gem.
- Move the unit test code to the specific projects
- Change the deployment scripts based on the new architecture.
Choices you need to make
- You need to decide how you want to split the functionality, based on API and background jobs, based on features, etc.
- You will come across cases where the models are required in more than one project, you either have to make a plugin or keep the code of the model in both projects.
- And finally, it's hard to find out how much benefit you would get out of this exercise of dividing the code, take your time to make your decision.