Ruby on Rails is a popular web framework that allows you to build scalable, enterprise-ready applications with complete front-end support. Rails is following the convention over configuration approach and its own set of standard conventions for naming, structure and configurations. Rails is an easy to use development framework but some of it’s projects are tough to manage due to the some wrong approaches that we are using while handling it. So here we’ve listed some common mistakes that Rails developers commit.

Most common mistakes in ruby on rails development-

1. Not using the correct rails application for your requirement-
Most of the web services apps are still using a traditional Rails web application. Why? What is the reason to use traditional Rials when you have all the latest one’s? New versions of Rails introduced API mode that is completely dedicated to build Rails API. If you don’t know then you can run the following command to create API app,

rails new [api_name] --api
It executes the unused and superfluous set of middleware like views, assets and so on. It starts the application with some needed middleware instead of loading unnecessary code libraries. Hence before starting development of your app analyse the purpose of application. If you’re thinking to develop web app then prefer the traditional rails web application. But if you’re building only API then prefer API mode application.

2. Putting too much logic in the controller-
We all know that Rails is based on MVC architecture. Moving view logic or domain/model logic into controller is easy. But the problem is, Controller object will start violating the single responsibility principle that makes future changes to the code base difficult and error-prone. Generally, the only types of logic should be in your controller are:

Session and cookie handling- This may include authentication/authorization or any extra cookie processing you have to do.
Request parameter management- Collecting request parameters and calling appropriate model method to persist them.
Rendering/redirecting- Rendering the result(html, xml, json etc) or redirecting as appropriate.
Model selection- Logic for finding the right model object given the parameters passed in from the request. Ideally this should be a call to a single find method setting an instance variable to be used later to deliver the response.
This still pushes the limits of single responsibility principle, it’s kind of a bare minimum that the rails framework needs us to have in the controller.

3. Excessive use of RubyGems-
RoR developers are lucky because they get a large number of gems to ease development. But some of the developers make excessive use of gems in their applications to the extent that gems’ use is more than functionality of the app. The main issue that arises from Gems’ excessive use is that your web app’s size increases and this reduces the app performance. Also, it requires more memory configurations and increased optimization costs. So your rails app takes more time to start that reduces development time. Also with each gem you add, dependency on another gem includes. So you increase the number of dependencies in your app, that creates lags in application. This is called the compounding effect. For instance, using a gem rails_admin creates dependencies for 11 more gems. So you should consider this before you use a gem.

4. Mistakes we commit in Rails ActiveRecord-
ActiveRecord is a great ORM feature in Ruby on Rails that will map database tables and models. It provides lot of methods to carry out database I/O operations. You must focus on future scope and challenges while building app architecture. Most of the developers don’t understand the working of ActiveRecord in rails. This can cause the performance issue in application.

For example, to check the record availability what query you will use? Here most of the developers will prefer to use either one of the options,

Option 1:

User.where(is_active: true).count > 0
=> SELECT COUNT(*) FROM "users" WHERE "users"."is_active" = $1 [["is_active", "t"]]
Option 2:

User.where(is_active: true).any?
=> SELECT 1 AS one FROM "users" WHERE "users"."is_active" = $1 LIMIT $2 [["is_active", "t"], ["LIMIT", 1]]
Which option is best to check record availability? Option 1 or Option 2? Option 2 is better. Why? There is a reason! Here we’re checking the availability of specific case. So only checking availability is not sufficient. No compelling reason to check the tally and discover the accessibility. So it’s prefer to use right option based on your use case.

know more at- [https://solaceinfotech.com/blog/most-common-mistakes-to-avoid-in-ruby-on-rails-development/]