In a normal Rails app, under app folder we have: assets, models, views, controllers, etc. What other folders should be created for best practices?
I read at places and projects, they create jobs, serializers, services, validators, channels. What all goes there? Also, what kind of code goes in the lib directory?
I want to post an answer here based on experience and research. Please mind that these are not conventions or must-do things. I have been using them this way (some of them). Since the detailed explanation of each will require a different question for each. I will refer links here:
Serializers: I use this for serialization of data. In rails, while rendering data as JSON, we have this beautiful Active Model Serializer library.
Jobs: I use this for implementing jobs. The jobs can be enqueued and executed using different queuing backend like Sidekiq, Resque, Delayed Jobs. Active Job Basics is a good documentation for this.
Mailers: I use this for implementing mailers i.e. mailing structure for my app. Here's the official documentation for Action Mailer Basics.
Channels: I use this for websockets for real time features. We can use action cable library for implementing real times features like posts, chats. Action Cable has been added to rails core and can be used as a replacement to gems like Faye.
Rules: I use this in my apps which requires rule engine implementation. Here are certain gems which provide rule engine in ruby: Wongi, Ruleby, Rules Engine, Rools
Services: These can be used to do the complex operations inside the app. In a modular rails app, we can tell the core of the app looking at the services folder. They provide decoupling, visibility, cleans controllers/models, accessible everywhere and easy to test. They can be used when action is complex or reached across multiple models or interacts with external service. If service gets complex, we can break it into other services. Examples are: GenerateReport, PublishWeekly, PayInvoice, RegisterUserWithGoogle. Here are the reads: Blog1, Blog2, Blog3, Blog4.
Queries: Database queries can go here. These can be used at different places across the application while hiding the query logic. It is also good for unit testing.
Forms: These handles forms in the application. They are mainly used to extract validations from Rails models. It is nothing but a simple Ruby class that includes ActiveModel::Model. We can use reform gem to implement this. Here are more details: ActiveModel Form Objects
Decorators: These can be used to replace helpers. See Draper gem.
Validators: Custom validators can go here i.e. of different attributes of model say email in user. Here's an example Custom Validators.
Responders: This is what we send back to server in response of request. Read more at: Responders. There is also responder gem that includes a set of responders modules to dry up. Many programmers also put this under lib/responders instead of app/responders.
Concerns: They are used to extract common and / or context specific chunks of code in order to clean up the models and avoid them getting too fat and messy. See here: ActiveSupport::Concern.
Uploaders: They are used to store file uploader configurations pertaining to certain gems: Shrine.
Please note that this is not necessarily a convention. The structure solely depends upon you and your rails app. Some projects may include further more sub directories like policies, support, actions, etc. for more DRYness and SRP (Single Responsibility Principle).
Refer:
http://blog.codeclimate.com/blog/2012/10/17/7-ways-to-decompose-fat-activerecord-models/
https://www.toptal.com/ruby-on-rails/decoupling-rails-components
For the lib, refer following links:
https://devblast.com/b/rails-app-vs-lib
https://gist.github.com/maxim/6503591
http://blog.codeclimate.com/blog/2012/02/07/what-code-goes-in-the-lib-directory/
This is based on my experience, research, knowledge and opinion and not on fact or convention that goes by any official guide.
