Popular Rails and Rails-way problems

Problems mentioned in: article on Shopify

• routing,
• before-actions,
• large actions in controllers,
• private methods in controllers,
• mixins used once,
• logic in views,
• ActiveRecord callbacks,
• Associations,
• “fat models.”

Additional problems

• Active Record Validations,
• implicit over explicit,
• abuse of DRY,
• delegations to associations,
• service calls in models.

Alternatives to Rails

When it comes to Rails in the Ruby world, we have several alternatives. Other frameworks based on Rack include: – Sinatra, – Roda, – Hanami.

What makes them unique?

Both Sinatra and Roda offer us a block routing syntax, but routing in Sinatra is a list and in Roda – a tree. In both frameworks, we have to deal with the implementation of the model layer ourselves. In the case of Roda, it is a good idea to use the Sequel gem.

Roda is inspired by Sinatra. It is very light in itself, but it has a lot of plugins.

Hanami is the closest to Rails when it comes to areas covered by the framework. The most important differences in terms of use are:

• controllers in Rails vs. actions in Hanami,
• dedicated classes / objects handling a specific HTTP request, not one controller for actions related to a specific resource (model),
• model layer based on repositories and entities, separating persistence from the rest of the application, not the active record pattern.

Hanami version 1 strongly limits the use of ROM it is based on (version 3, and it is already 5), so it is not worth using the model layer proposed there. However, as it is a very open framework, it is quite easy to implement there the model your own.

Supplements for Rails

It’s worth using solutions that aren’t dependent on Rails and are closer to “pure” Ruby. The tools mentioned in the presentation are:

• Sequel (ORM, alternative to ActiveRecord),
• ROM (object mapper),
• dry-rb libraries: dry-validations, dry-system and dry-monads.

Sequel is easy to put in a project, it is based on plugins and also implements the active record pattern. It has better low-level query support than Rails‘ ActiveRecord.

ROM uses Sequel, but its concept is to translate between records in the database(s) and Ruby objects. It aims for speed and data transformation. Clearly separates the persistence layer in the application.

Dry-rb libraries are very useful tools:

• dry-validation is very easy to use in API projects and allows for great control over the correctness of incoming data,
• dry-system needs a bit of pratcice and patience for the developers to understand it, but it allows for very flexible management of dependencies in the application and loading project components in isolation; if we want to use this library in Rails, we can use dry-rails,
• dry-monads is a difficult concept in theory, but in practice it is easier to understand, the result monads can be a great way to increase the readability of code by considering specific cases instead of branching ifs.

Conclusions

It’s best to use Rails so that you don’t have to use Rails one day.

Sources

Articles

• Code Smells in Rails Apps (by Shopify)
• Hanami: repozytoria
• Rails Guides

Frameworks

• Sinatra
• Roda
• Hanami

Gems

• Sequel
• ROM
• Biblioteki dry-rb
• Ruby JSON Schema Validator (json-schema)
• Pagy
• Rodauth
• rodauth-rails

Specifications

• Rack
• JSON Schema

Read more:

What is Ruby on Jets and how to build an app using it?

Vuelendar. A new Codest’s project based on Vue.js

Codest’s weekly report of best tech articles. Building software for 50M concurrent sockets (10)