Unegbu
Kingsley

Introduction

Devise, a powerful authentication gem for Ruby on Rails, offers a variety of tools for managing user authentication. Among these is the authenticate method, which can be used directly in routing to restrict access to specific resources or paths. This feature allows developers to define access control at the routing level, providing a clean and straightforward way to secure parts of their application. Here is a simple block.

Rails.application.routes.draw do
  authenticate :user do
    resources :posts
  end
end

In this article, we’ll explore how the authenticate method seamlessly integrates with the Rails routing block.

Problem

One thing to note is that the above code will throw an error if the devise gem is not installed. This indicates that the authenticate method is provided by the devise gem. The question then arises: how do these Devise methods integrate so seamlessly with Rails’ structure?

Prerequisite Knowledge

• Monkey Patching: A way to dynamically modify code behaviour without changing the main source code. Check this article for more understanding.
• Mapper Class: All valid method used in the routes block are found in the ActionDispatch::Routing::Mapper Class. You can find the source for these class here. The get, post, resources methods are all defined in these class.

The Answer

As you may already know, at least from the prerequisite section, valid methods in the Rails routing block are defined within the Mapper class. If you want to make a method valid inside the routing block, you need a way to register this method in the Mapper class. This is where monkey patching comes into play, and it’s exactly what Devise does. You can find the source code from here. Let’s also add a short snippet here.

module ActionDispatch::Routing
    ...
    class Mapper
        ...
        def devise_for(*resources)
            ...
        end
        ...
        def authenticate(scope = nil, block = nil)
            ...
        end
        ...
    end
end

You may notice other methods that are equally valid in the Rails routing block when the Devise gem is installed.

Conclusion

You can see how Devise leverages monkey patching and a deep understanding of Rails to extend its functionality and provide such an elegant API for authentication. This approach demonstrates how you can enhance Rails’ capabilities in your own libraries.

Caution: Monkey patching can be a potential source of serious bugs and maintenance challenges. Whenever you use monkey patching in your project, proceed with caution and ensure you have a solid understanding of Rails. Happy coding, and thank you for reading!

Devise: Monkey Patched ‘authenticate’ was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Most of us, as Rails developers, have used gems, and we need to set some configurations for the gem. let’s pick a gem for example. Let’s use “Kaminari”. A rails gem for pagination. we can set “default_per_page” config property as follows:

Kaminari.configure do |config|
  config.default_per_page = 10
 end

in Rails initializers folder.

And we can now access this configuration as follows:

Kaminari.default_per_page

With all this, we can ask the question How is this implemented from the Gem standpoint? and, How does ActiveSupport::Configurable help?

To kick off, let’s implement this without active support.

Without Support

Let’s implement the configuration structure. You can also see how Kaminari implements theirs by following this link.

We created the Kaminari module with “Configuration” class in it. the Configuration class has the “default_per_page” property.

module Kaminari
  class Configuration
      attr_accessor :default_per_page
  end
end

next, let’s add the module method/instance that will hold the configuration instance.

module Kaminari
  class Configuration
      attr_accessor :default_per_page
  end

  class << self
    def configuration
      @config ||= Configuration.new
    end
  end
end

With this instance created, what’s left, is to create an API that users will use to set configurations. For this, we create the “configure” method.

module Kaminari
  class Configuration
      attr_accessor :default_per_page
  end

  class << self
    def configuration
      @config ||= Configuration.new
    end

    def configure
      yield configuration if block_given?
    end
  end
end

Awesome, we have created the configuration setup. We can now set the configuration value for our module.

Kaminari.configure do |config|
  config.default_per_page = 20
end

Nice. Let’s access the configuration value for “default_per_page” which we just set. We do this as follows:

Kaminari.configuration.default_per_page   #20

But one thing we will notice is that “configuration” is in the path. This is unnecessary (arguable). We can fix this by using ruby metaprogramming “method_missing” method. Let’s define it.

module Kaminari
  class Configuration
      attr_accessor :default_per_page
  end

  class < self
    def configuration
      @config ||= Configuration.new
    end

    def configure
      yield configuration if block_given?
    end

    def method_missing(m, *args, &block)
      return configuration.send(m, *args, &block) if configuration.respond_to?(m)
      super
    end  
  end
end

With the “method_missing” defined, we can now go ahead and access the value directly. as follows:

Kaminari.default_per_page    #20

pheeeewwwww. Ok, now that’s all for creating the configuration setup without active support.

Active Support

Ok, we have seen how to implement the configuration setup without active support, let’s see the other side.

First, you install the “active_support” gem. You can see how here. let’s write our module.

require "active_support/configurable"

module Kaminari
  include ActiveSupport::Configurable
end

With the above code, we can set our configuration value and call it. as follows

Kaminari.configure do |config|
  config.default_per_page = 80
end

And call the value as follows:

Kaminari.config.default_per_page     #80

Two things to note. We are using “config” in the path in the above code. Not “configuration” that we used in our setup. This is because that’s what active_support chooses to name theirs.

Secondly, as we said earlier, having “config” in the path to call the value is unnecessary. Let’s fix that with the following code.

require "active_support/configurable"

module Kaminari
  include ActiveSupport::Configurable

  config_accessor :default_per_page
end

With the following fix, we now call the value as :

Kaminari.default_per_page        #80

Which is our goal. Nice!!!

We can see how active support configurable does some heavy lifting for us.

Conclusion

I went through this to show you how active support configurable helps in configuring your gem, module, or class.

There are other things that active support gives. One of which is instances of configurable classes also have access to the config object.

You choose which method you would go with.

Thanks for your time and attention. Keeps coding.

Active Support: Configurable was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

If you had programmed for some time, you would have come across class Variables. Most Programming language has it. It is a variable that belongs to the class itself. Taking the definition from Wikipedia

A class variable is a variable defined in a class of which a single copy exists, regardless of how many instances of the class exist.

Language like C# and Java uses static keywords to define it. But this article is a Ruby(Beautiful Language) article, so let’s see how it is implemented and its weird quirks.

The Two Ways To Diamond

To show the two ways to implement class variables in ruby, we will implement a class that creates instances and stores how many instances are created from the class. We will also add a class method that prints the number.

1. Class Instance Variable (@)

code is as follow:

class Fruit
  @instance_count = 0

  def initialize
    self.class.increment_instance_count
  end

  def self.instance_count
    @instance_count
  end

  def self.increment_instance_count
    @instance_count += 1
  end
end

Fruit.new
Fruit.new
Fruit.new
Fruit.new

p Fruit.instance_count    #4

Let’s take a while to explain this code. First, a very important key to note in this code is “in ruby, everything is an object”. Objects have instance variables that are private to them.

In the second line, we initialize the class instance variable (not just an instance variable but a class instance) “@instance_count” to zero. Since instance variables are private, we need a function to expose this variable. Hence, we created the “increment_instance_count” class method to increment the instance variable. And “instance_count” to output the instance variable. Lastly, we call the class “increment_instance_count” method in the “initialize” method because it is always called when a new instance is created.

Importantly, something to take note of is the “self.class” in the initialize call.

self.class.increment_instance_count

This is important as “initialize” is in the context of the instance variable. That is self here refers to the instance. So we need the class of the instance and then call “increment_instance_count”.

2. Class Variable (@@)

code is as follow:

class Fruit
  @@instance_count = 0

  def initialize
    @@instance_count += 1
  end

  def self.instance_count
    @@instance_count
  end
end

Fruit.new
Fruit.new
Fruit.new
Fruit.new

p Fruit.instance_count  #4

This way, we remove some of the complexities of the earlier version. We are using “@@instance_count” which is not private to the class. It is accessible to the instance, hence, we don’t need the “increment_instance_count” method from the earlier version to increment. We can increment it as shown in the initialize method.

def initialize
    @@instance_count += 1
  end

The Weird Quirk

From the two versions, the second way seems to be the way to go for its elegance and simplicity. But there is a caveat. There is something you need to have in mind while using @@.

It is shared across ancestors line

This means that any member of the ancestor has access to change the value and query the value.

From our example, we have a class “Fruit” if call the ancestor as follows

p Fruit.ancestors   #[Fruit, Object, Kernel, BasicObject]

We get an array. If any of these objects in the array edit the value of “@@instance_count”, it will reflect and skew our program.

Currently, none of the objects is changing the value, so our program runs as expected. However, it is worth knowing that ancestors can update/edit the values of class variables.

CONCLUSION

Ruby is an interesting language that has multiple ways of doing different things. I showed a little hidden fact about class variables that will enable you to choose the right tools while designing your software system.

As always thanks for your time and happy coding.

Have you ever handled exceptions in your ruby code? If so, then you would have come across “rescue”. Let’s see an example for a refresher.

def handle_exception
  raise "The exception"
rescue
  p "Exception Rescued"
end


handle_exception      #=> Exception Rescued

If we run the following code, we get “Exception Rescued” on our terminal. That’s self-explanatory.

But what if we want to use some properties of the exception inside the rescue block? Let’s say we want to print out the exception message rather than “Exception Rescued”. One way to do that would be as follows:

def handle_exception
  raise "The exception"
rescue => e
  p e.message
end

handle_exception      #=> The exception

This way, we are assigning the exception into the variable “e” and printing out the message to the console.

As a note, it is advised to specify the exact exception you are catching for better code.

In this case: “RuntimeError”

Constant Way

Another way of achieving this is to use the ruby “$!” constant as follows:

def handle_exception
  raise "The exception"
rescue
  p $!.message
end

handle_exception      #=> The exception

You will notice that the “e” variable is no longer there. we can access the exception from the “$!” constant. This constant is always nil when used anywhere else in your ruby code. It only always has a value within the rescue block.

This is a nice tip to have while writing or reading code. Thanks for your time and happy coding.

After instantiating your rails application, we have codes generated for us. Let’s focus on a particular section. Focus on the environments section. That is the “config/environments” folder. This folder will contain three files to set up rails behavior in different environments.

Looking at any of these files will bring us to the question we want answers to in this article.

The following is a sample of the file (without the comments).

Rails.application.configure do

  config.cache_classes = true

  config.eager_load = true

end

The Question

If you look at the code, you will notice something. “config” is being used everywhere. But the question is, Where is “config” coming from? Where is “config” defined?

It seems magical. An ideal scenario would be that “config” was passed as a parameter. Like this.

Rails.application.configure do |config|

  config.cache_classes = true

  config.eager_load = true

end

So why does the original code work without the parameter? Let’s dig a little.

Unveiling the Trick

First, we need to understand that the “Rails” module object has an “application” instance object which is created when we inherit from “Rails::Application”. This is not in the scope of this article. Trying to explain the first line, why “Rails.application”.

The application instance has a method “configure”. This method is an inherited method from “Rails::Railtie”. You can find the code here.

 def configure(&block) # :nodoc:
      instance_eval(&block)
 end

As you can see from the above code, the method accepts a block as an argument. So the block from the first code block of this article is passed to this argument.

Now we have gotten to the heart of the trick. And it is “instance_eval”.

“instance_eval” is a method that accepts block or string. passing the block to it executes the content of the block as though it was defined in the object.

When the block is running and trying to run “config”, it checks in the application object context and uses it. We can see that “config” was defined in the application instance here.

def config
      @config ||= Railtie::Configuration.new
end

In other words, “instance_eval” gives us a portal into the “application” instance object. So we can use other methods and variables inside the “application” instance object in the block not just “config”.

Conclusion

I have shown that the reason for this confusing part was because of the “instance_eval” giving us portal access to the application instance. Hope I helped better understand this Rails-generated code and give you confidence in editing it and creating better programs.

As always thanks for your time and happy coding.

Rails: Environment Configuration (Magical) Instance was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.

Ruby On Rails Structure

We all love Ruby. Well if not all of us, I do. Which other framework has been more impactful in the ruby community than Ruby on Rails. A beautiful web framework that favors convention over configuration. Gives incredible speed in development.

But let’s look a little under the hood and see how this beautiful framework architect itself.

The first thing to note is in the ruby world, libraries are called GEMS. Gems are reusable, shareable code that you deploy. You deploy this code to rubygems.org. With that out of the way, let’s speak of the architecture.

The Architecture

When using Rails you love how it just works. Behind it, Rails is just a combination of libraries (gems). Let’s list out these gems.

ActiveSupport
ActionCable
ActionMailbox
ActionMailer
ActionPack
ActionText
ActionView
ActiveJob
ActiveModel
ActiveRecord
ActiveStorage
Railties

Some of these libraries (gems) depend on other of it library. One library that all other libraries depend on is ActiveSupport. It is the lowest-level library. like the foundation. I will also encourage you to use them in your project because it comes with lots of helpers that improve Ruby and ease your coding experience.

You might then ask, so what? what does listing these gems have to do with me?

Well, one thing I would like to pass it that all these libraries are independent. If you choose you can pick one and use them in your project. And it does not mean you are using rails. Even though the Rails team created these libraries, they decoupled them and made them independent.

Railties

But one library (gem) with is very tight to rails is the Railties library. This is the core of rails. All libraries that need Rails core feature need to add this as a dependency. Since Rails created all these libraries, all of its libraries use Railties.

“How would you know if a library is using this “Railties” library?” you may ask. You would know if they have a file named railtie, or engine that inherits from Rails::Railtie, or Rails::Engine.

Rails use this library to tie everything together.

Conclusion

Most people see rails as one complex structure and yes they are right. But seeing the inner architecture will allow you to appreciate and possibly benefit from its inner libraries in your projects. For a project where you need to communicate with a database, ActiveRecord can be of use. And you don’t need to use the whole rails.

Thanks for your time and happy coding.

If you have ever written a Rails application, you would be familiar with the Gemfile. But the Gemspec file would be familiar if you have written a Gem. Rails Plugin/Engine are Gem.

These files are different with one big similarity.

Gemspec is closely similar to package.json in the javascript world. It defines the author’s name, email, license, dependencies, and so on. check below block for a sample.

Gem::Specification.new do |s|

  s.name        = "raile"
  s.version     = version
  s.summary     = "Full-stack web application framework."
  s.license = "MIT"

  s.author   = "Mark"
  s.email    = "mark@raile.com"
  s.homepage = "https://raile.org"

  s.files = ["README.md", "MIT-LICENSE"]

  s.add_dependency "activesupport", version
  s.add_dependency "actionpack",    version

end

Gemfile is mostly a dependency manager. Make sure all codes which you depend on are available. From any source. check below for a sample.

source "https://rubygems.org"
gemspec

gem "minitest", ">= 5.15.0", "< 5.22.0"

gem "sprockets-rails", ">= 2.0.0"
gem "propshaft", ">= 0.1.7"
gem "capybara", ">= 3.39"
gem "selenium-webdriver", ">= 4.11.0"
gem "rack-cache", "~> 1.2"
gem "stimulus-rails"

The Problem

With the introduction out of the way, you might ask so what? why are we talking about them?

One thing you should notice is that Gemspec has dependency management (s.add_dependency) as one of its features. And Gemfile’s sole purpose is to manage dependencies. That brings us to the problem. They are doing similar jobs. And it becomes confusing if you have a project that has both files. Where do you put your dependencies? Which one is the right place? Are some dependencies supposed to be in one and others in the other?

The Rationale

This will become clear if you look at it from the installation. Look at it from where is the Gem being installed. Is it being installed on the system or an application?

Let’s take an example of a Gem (food_tracker) you are working on that has these two files (Gemfile and Gemspec). After you are done with the Gem you publish the Gem to rubygems.org.

A user wants to use your Gem on a system level and installs your Gem with the following command

gem install food_tracker

This will install the Gem using the dependencies from Gemspec alone.

If the user wants to install it on an application they too are working on, they add your Gem to their application Gem file (gem food_tracker) and run

bundle install 

Then, this will install your Gem and dependencies from Gemfile. But there is a caveat. In the Gemfile, we are also calling the Gemspec file. We can see this in the second code block of this article a method gemspec.

gemspec

With all this, it means that installation with Gemfile uses dependencies defined in the Gemspec file. But it is not the same the other way round.

So all breaking and important dependencies should be defined in Gemspec file.

Conclusion

With all this I hope I relieve any confusion if you see projects that have Gemfile and Gemspec files with dependencies.

Thanks for your attention and happy coding.

All of us rails developers have used generators before. Either it is when we run rails new or rails generate scaffold. These commands generate files that are needed or help you run our application. The question then becomes, How does Rails find this Commands script? Where are the script defined?

NB: If you are not aware, generator commands are classes that inherit from Thor. In Rails source code, Thor is subclassed in the class called Rails::Generators::Base.

The Question: How do Rails Find This Generators

So Rails is doing two things here.

Firstly, Rails is taking note of every class that subclasses the Rails::Generators::Base. And stores this class in an instance variable (subclasses)of the Rails::Generators module. We can see this here.

  def self.inherited(base) # :nodoc:
        super

        # Invoke source_root so the default_source_root is set.
        base.source_root

        if base.name && !base.name.end_with?("Base")
          Rails::Generators.subclasses << base

          Rails::Generators.templates_path.each do |path|
            if base.name.include?("::")
              base.source_paths << File.join(path, base.base_name, base.generator_name)
            else
              base.source_paths << File.join(path, base.generator_name)
            end
          end
        end
      end

Secondly, Rails get the first argument from the command. Let assume the command is as follows:

rails g controller authentication

Rails gets “controller” as the first argument, and adds it to an empty array. Something to note is that I am using a simple case to explain this. It is possible to call the generator as follows.

rails g {name}:controller authentication

This will make the array contain more than one element. This code that does the separation.

   def invoke(namespace, args = ARGV, config = {})
        names = namespace.to_s.split(":")
        .
        .
        .

With this, Rails makes a lookup call. The method definition for the lookup call is defined in a separate module (Rails::Command::Behaviour). This lookup method first converts the array to paths. That is it converts all “:” to “/” and append the last word after the last “:”. For example, it converts [“first:second”] to [“first/second/second”]. The line is as follows.

 def namespaces_to_paths(namespaces)
            paths = []
            namespaces.each do |namespace|
              pieces = namespace.split(":")
              path = pieces.join("/")
              paths << "#{path}/#{pieces.last}"
              paths << path
            end
            paths.uniq!
            paths
end

After this conversion, Rails performs some permutations. It uses a hard-coded array to permutate the earlier array to load the correct file. We can find the hard-coded array here.

["rails/generators", "generators"]

After this permutation, we then have the module “Rails::Generators::Controller” loaded from our “controller” example.

With the class loaded, we need to call the start method on the class. You might ask why the “Start” method. The answer is, that’s how Thor works. Thor uses the “start” method to run the script in the class.

Rails chooses the class to call start on by converting the subclasses from step 1 to a hash using the returned value of the method namespace in the class as key. And matching the keys to that of the initial array. We can find this here.

        namespaces = subclasses.index_by(&:namespace)
        lookups.each do |namespace|
          klass = namespaces[namespace]
          return klass if klass
        end

Where Rails Store the Generators Code

All rails generators are stored in the directory path “railties/rails/generators/rails”.

Conclusion

Rails use some complex architecture to find generators. There are some details I miss to not make the article long. But I have to clarify the path and direction to understand the underground workings.

Thanks for the attention and happy coding.

In our rails applications, there is a file where we register all our routes for the application. These may be endpoints for our API application. Or routes to webpages for full-stack applications. This file is the routes.rb file. Which can be found in the path /config/routes.rb.

We add paths to this file, and like magic, it’s working. We now have our endpoint /api/foods working. We are good to go.

The Question: When is Rails creating this Routes

A question that might hit you when you are wearing your curiosity hat might be, When do Rails execute the file? How does Rails know to check this file for my application routes?

The Answer: The Bus

The answer starts from understanding “railties”. This is a link to a railtie article. At the core of rails, everything is a railtie.

Ok, you understand what is a railtie now, then how does it relate to what we are discussing?

The relationship is that your Rails application itself is a railtie. Your application which is registered in config/application.rb.

module MedicoBackend
  class Application < Rails::Application
.
.
.

From the code above, our application only inherits from Rails::Application, but Rail::Application inherits from Rails::Engine, who in turn inherits from Rails::Railtie.

So as we can trace our rails application heritage to Rails::Railtie, it is a Railtie.

If you understand railtie, we know railtie’s add code to be run during Rails initialization. Since our application is a railtie, it can do just that. And that’s what our Rails application is doing. It adds some codes to run the routing file and adds our routes during application initialization. We can see that if we go to the rails source code.

initializer :add_routing_paths do |app|
  routing_paths = paths["config/routes.rb"].existent
  external_paths = self.paths["config/routes"].paths
  routes.draw_paths.concat(external_paths)
  app.routes.draw_paths.concat(external_paths)

  if routes? || routing_paths.any?
    app.routes_reloader.paths.unshift(*routing_paths)
    app.routes_reloader.route_sets << routes
    app.routes_reloader.external_routes.unshift(*external_paths)
  end
end

The initializer method call is the way to add an initilization step to rails. Rails uses the above code block to add the initialization step to setup the application routes. And as you can see, rails is checking for the config/routes.rb file first before checking for other registered external routes.

Conclusion

We can see how Rails application uses it feature as a railtie to run code during initialization. And how it checks for that specific file for routes definitions.

We can also add our own custom route file, but that will be another topic.

I hope, I helped clarify the magic of how rails executes the routes file and other little bit of information. Thank you for your time and happy coding.

If you have ever worked with Rails, you would have seen the application file. Located in the config folder (/config/application.rb). This file is where we register rails gems that need to load some code on rails initialization. These files are called “Railties”

require_relative 'boot'

require "rails"
# Pick the frameworks you want:
require "active_model/railtie"
require "active_job/railtie"
require "active_record/railtie"
require "active_storage/engine"
require "action_controller/railtie"
require "action_mailer/railtie"
require "action_mailbox/engine"
require "action_text/engine"
require "action_view/railtie"
require "action_cable/engine"
# require "sprockets/railtie"
require "rails/test_unit/railtie"

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

module MedicoBackend
  class Application < Rails::Application
.
.
.

In a scenario where you want to load some code during rails initialization, you can consider writing your own railtie. You can use this article as a guide.

The Question: Billion Ruby One

When we see this file, we add our railties there and be done with it. But, how about we ask, how is it possible that Rails can run the code with just requires to class definitions? Where is Rails initializing these classes? Is Rails checking this specific folder?

Let’s try to answer these questions and have clarity.

The Starting Point: On your Mark

The genesis of answering this question is from the environment file. Which is also located in the config folder (/config/environment.rb). This file calls the application file and initialize! function.

# Load the Rails application.
require_relative 'application'

# Initialize the Rails application.
Rails.application.initialize!

The first line calls the file which registers all the railties. The file that made us interested in this article.

The intialize!: Rabbit Hole

The second line is the start of the rabbit hole. this line calls the initialize! method defined in Rails source code. It is defined in the Application class which our application inherits from. the source.

 def initialize!(group = :default) # :nodoc:
      raise "Application has been already initialized." if @initialized
      run_initializers(group, self)
      @initialized = true
      self
    end

As you can see, intialize! method in turn calls the run_initializers. this method is in a module file in Rails. it is accessible to this call because the superclass (Rails::Railtie) included the module in its definition. the source.

    def run_initializers(group = :default, *args)
      return if instance_variable_defined?(:@ran)
      initializers.tsort_each do |initializer|
        initializer.run(*args) if initializer.belongs_to?(group)
      end
      @ran = true
    end

    def initializers
      @initializers ||= self.class.initializers_for(self)
    end

Moving forward. As you will notice in the earlier block of code, I added another method initializers. I added that because it caused me a whole lot of confusion. Let me explain.

In the method run_initializers, we call initializers. You would think that the method I added was what is being called, but it is not. Ideally, you would be correct but, Application class has overridden this method. So the other method was what was being called. the source.

  def initializers # :nodoc:
      Bootstrap.initializers_for(self) +
      railties_initializers(super) +
      Finisher.initializers_for(self)
    end

This caused me a lot of frustration. This method then calls the railties_initializers method. the source.

def railties_initializers(current) # :nodoc:
      initializers = []
      ordered_railties.reverse.flatten.each do |r|
        if r == self
          initializers += current
        else
          initializers += r.initializers
        end
      end
      initializers
    end

railties_initializers method calls ordered_railties method. the source.

  def ordered_railties # :nodoc:
      @ordered_railties ||= begin
        order = config.railties_order.map do |railtie|
          if railtie == :main_app
            self
          elsif railtie.respond_to?(:instance)
            railtie.instance
          else
            railtie
          end
        end

        all = (railties - order)
        all.push(self)   unless (all + order).include?(self)
        order.push(:all) unless order.include?(:all)

        index = order.index(:all)
        order[index] = all
        order
      end
    end

Following the pattern, ordered_railties then calls railties method. the call is on the line 13 (all = (railties — order)). the source.

def railties
      @railties ||= Railties.new
  end

At last, we meet the real culprit. Railties.new. This code is initializing a class. Let see the class. the source.

# frozen_string_literal: true

module Rails
  class Engine < Railtie
    class Railties
      include Enumerable
      attr_reader :_all

      def initialize
        @_all ||= ::Rails::Railtie.subclasses.map(&:instance) +
          ::Rails::Engine.subclasses.map(&:instance)
      end

      def each(*args, &block)
        _all.each(*args, &block)
      end

      def -(others)
        _all - others
      end
    end
  end
end

From the class, you can see in the initialize method, that Rails is calling the subclasses method of Rails::Railtie. Which if you remember is a pre-requisite of creating a railtie. the subclasses method will return all the classes we registered. Instantiate it by calling the instance method on it and then rails run the codes you add on it.

NB: The subclasses method is defined in rails (ActiveSupport). But as of ruby 3.1, ruby have added subclasses to classes. Another article to dig into that.

Conclusion: Climb Out

It’s time we climb out of the rabit hole. We can see that rails is using the base class to fetch all the subclasses and then initialize them and run code in them. So no, rails is not checking a specific folder.

Thanks for your time and happy coding.

Rails: Understanding Railties and How it’s Registered was originally published in DevOps.dev on Medium, where people are continuing the conversation by highlighting and responding to this story.