Life is all about learning new things all the time, but why would we like to learn something if we can’t share it in an app of rails.
That’s exactly what Jack Danger Canty (@jackdanger) did at GoGaRuCo 2012; share knowledge and experience. Well, all of the speakers did that, but, this is one of the talks I enjoyed the most, why?
Well, because I’ve been coding Ruby for about 9 months now, but, I’ve never coded in a big and robust app that runs in multiple data centers with big MySQL boxes and thousands of controllers, or as Jack named it, a Mega Rails.
I’ve just been coding apps with Rails, a bunch of gems, one database, MySQL and other simple stuff, or as Jack named it, a Mono Rails: an app that you can host in a single server with nice hardware and boom! you’re done.
But what happens when a Mono Rails gets bigger and bigger, until it becomes a Mega Rails. How do we handle that? How do we keep things steady and cool within our growing app?
So here are a couple of things I learned from Jack at GoGaRuCo. If you haven’t faced any of these problems before, like me, you may find this useful. And if you have, well then maybe you can add some #ProTips in the comments below and share your knowledge!
Databases
While keeping a Mono Rails, it’s ok just to have one database server, but if you start growing, you should really consider having many of them (a cluster).
Database Management System
It’s ok to have both Postgres or MySql. But, you should consider PostgreSQL for a Mega Rails, since Postgres is better at handling high concurrency, and it’s well known for being rock-solid and well-engineered.
Let’s say you want to change a default value in MySQL, it would take forever as it needs to do an entire table copy, and Postgres will not.
Keeping your users thin
Avoid having a lot of columns on your users table, let it hold authentication data exclusively.
Use other models for any other data like name, address, date of birth (Profile, Account, etc).
Validations
Use database constraints, instead of just using Rails standard validations validates_presence_of.
Why?, let’s suppose that your app runs, not only in ruby, but java and node.js as well, and, maybe some of these modules have different validations. If you use database constraints, you’ll have all your validations centralized instead of handling validations in every framework or language your app runs in. This way you guarantee data consistency across all environments.
Leave code behind
Remember to delete, move and add new files instead of just modify and add code to a file, to avoid ending up with thousand line files.
Conclusion
These were some of the tips that I remember the most from Jack’s talk. I’m sure there is still lots of other things we can do to make our app better and it’s up to you to use them or not.
Definitively this talk did set me up with possible solutions for future incoming problems and I thank GoGaRuCo for that, so, if you have any chance to go to a conference like this, you shouldn’t hesitate, there’re lots of people sharing experiences that might be useful for you in the future.
Thanks for reading!
