I've been using Rails for 2 years now, and feel confident enough. However, I don't know what I don't know. Below are a few examples of concepts I've learned over the years that aren't mentioned in beginner tutorials.
* Single Table Inheritance
* ActiveRecord::Enum
* Using Scopes
* Avoiding N+1 Queries
What are some other concepts or best practices do you recommend?
Thanks!
What does your overall app architecture look like.as things get more complicated?
> Single Table Inheritance
IMO, don’t use this regularly. Only use it in very specific cases. It causes maintenance issues over time.
> What are some other concepts or best practices do you recommend?
Generally speaking, understand Rails best practices. You don’t necessarily need to treat each one as gospel, but at least know where the industry is moving in general. So, read up on stuff like [Sandy Metz’s rules](https://robots.thoughtbot.com/sandi-metz-rules-for-developers) and [Service/Query/etc Objects](https://codeclimate.com/blog/7-ways-to-decompose-fat-activerecord-models/).
And then also, start to understand how the rest of the stack works. How does a database work? Knowing this will help you build more effective models and data structures. Knowing SQL well even though you have ActiveRecord will help you identify things like N+1 queries, issues where you’re missing an index, issues where you do actually need to break out of AR, or just generally prep you for larger scale projects. Learn about how web servers operate – what’s a load balancer, for example? Background/async jobs. What’s a crontab? Etc etc..
Learn to use less Rails (i.e. encapsulate domain logic in POROs).
Service Objects
Testing! Rails has a rich testing ecosystem that supports a number of styles of test. You can learn a lot about testing in Rails that will apply to any language/framework.
**SQL.**
Especially in the dialect of SQL you most commonly use as the backend for the application(s) you work on the most frequently. Specifically indexing and database performance tuning as you can leverage that knowledge to performance-tune your Rails apps. _Learn how to read those query-execution plans._ If you use PostgreSQL I highly recommend [PEV](http://tatiyants.com/pev/#/plans/new) to help with this.
SQL fluency isn’t even a Rails concept/best-practice per-se, but SQL _familiarity_ (much less fluency,) is one of the weakest skills I see when I’m hiring green Rails developers.
Besides, having strong SQL skills is a valuable cross-language/framework skill to have.
Learn how to work with more than the MVC that Rails provides using design patterns that Rails use and that you can use with Rails:
\- NullObject
\- ServiceObject
\- PolicyObject
\- ViewObject (Presenter)
\- Decorator
\- ValueObject
\- FormObject
\- QueryObject
(…)
* Most of the time it’s better to write your code which is readable and maintainable even if it’s not the most optimised
* Avoid writing long methods, prefer lots of methods with meaningful names. Almost all methods should be about 5 lines max. And should not use variables much.
* Use services classes that do only one thing with only one public method
* Use memoization [https://www.justinweiss.com/articles/4-simple-memoization-patterns-in-ruby-and-one-gem/](https://www.justinweiss.com/articles/4-simple-memoization-patterns-in-ruby-and-one-gem/)
Quick example :
class ImportUserBankBalanceService
def initialize(bank_api_client, user)
@bank_api_client = bank_api_client
@user = user
end
def call
raise “Error fetching bank balance:, #{external_resource.error}” if external_resource.error
user.update!(external_resource.data)
end
private
attr_reader :bank_api_client, :user
def external_resource
# this memoization pattern allows us to only fetch the data once but call the method multiple times
@external_resource ||= bank_api_client.fetch_balance(user.external_id)
end
end
use rubocop
I thing to be a good dev, it’s better to learn concepts outside rails. Look at sinatra and hanami, check out different orms (rom, sequel) and different approaches (dry and trailblazer). It’s also make sense to look at different languages.
Experience you’ll get learning things outside the rails’ box is universal,