In working with several Rails code bases over the years, I’ve picked up a few best practices to keep in mind from day one. The list below is by no means comprehensive, but sticking to it makes life much easier exactly when you need it most. Having good habits in place early on keeps things from getting out of control during emergencies.
- Keep Git Clean - Configuration doesn’t belong in the git repo. Like ‘database.yml’ for example. Under normal circumstances devs on each project will have varying setups for their development databases. If ‘database.yml’ gets shared, you’ll quickly find yourself fighting with configuration issues instead of working.
- API Keys Don’t Belong in Code - New developers commonly stick API keys directly in the code. This is a sure-fire way to set yourself up for failure. When relying on external services, it’s always best to make sure there is as little coupling as possible, between them and your code. Say, for example, there is a security concern at your payment processor, forcing them to reset all API keys. If you’ve taken the time to setup and use something like Figaro and Heroku ENV vars, changing an API is as simple as changing the key and restarting the app. Otherwise, you’re stuck redeploying the entire codebase for a small change.
- Avoid “match” In Routes - There is a change coming down the pipe that will depreciate the ‘match’ method. The primary concern here is leaving yourself open to CSRF attacks. If you can GET to a route you intended to only be a POST method, well… you’ll find out why that’s a problem soon enough.
- Don’t Add an “admin” Boolean to User - I’m a big fan of Rolify for managing user roles in Rails. A common approach is to simply add an “admin” toggle in the User record. Watch how quickly this falls apart when you have a dozen different roles in your app. This is a great example of mixing concerns. Your User record is not the right place to handle roles and authorization.
- Use Namespaces To Stay Organized - Multiple Rails apps right off the bat is a risky move. Lot’s over overhead, lot’s of duplication of code. Instead, keep your app roles inside their own namespaces (or Rails Engines, but let’s talk about that later) to make it easier to begin splitting things off later on. Untangling a web of controllers, roles, and concerns later on is expensive and complicated.
A few points to keep in mind, based on my working experience in the early days of development, thus far.