00:00:12.480
Welcome. I invite you to see a talk about the Rails boot process, and I would like to explain the goals of this talk.
00:00:20.290
In this talk, we are going to explore several aspects related to this topic.
00:00:27.849
For instance, if you open the config directory, there are a number of files that we normally never touch, such as config/boot.rb or the config/environment.rb files. We will see what they do.
00:00:40.810
Rails components, in general, can work independently of Rails. For example, Active Support and Active Record are libraries that you can use in Ruby scripts that are not running within a Rails application.
00:00:48.600
You can even have a regular Ruby script using Active Record, connecting to everything you need. However, when you launch a Rails application, all these independent components are somehow organized for you.
00:01:06.850
There's nothing the programmer has to do to get these components working together, and we are going to see how that works. The goal is to gain a better understanding of what happens during the boot process.
00:01:35.950
I say 'more or less' because there's a lot happening, but we will come away with a good sense of the sequence of events. For this talk, we need to consider a few things. First, the approach is tailored for Rails beginners.
00:02:02.319
This will not be a deep dive into code, showing you the entire code path. We will see some code snippets, but I have heavily edited these snippets to focus on the relevant details for understanding the boot process.
00:02:30.650
Additionally, we will ignore Spring and focus on the vanilla Rails process without any additions. Normally, when you think about booting a Rails application, you might picture launching the server, which serves requests.
00:03:39.100
However, there are more components involved in the boot process. When you run the console, the application is already available. The same applies when running scripts using the runner command. This means that the application has been booted to run these commands.
00:03:56.590
To understand Rails initialization, we can explore the bin/rake file. This file is generated in any modern Rails application and begins by loading config/boot.rb. If we open this file, we'll see that it configures the load paths for the bundles.
00:04:26.580
This setup ensures that the application can require the gems listed in the Gemfile. By managing the load paths, Rails can load the desired gems and ignore any that are not included.
00:06:19.940
After loading config/boot.rb, the config/environment.rb file is executed. This file loads the application and is typically where developers start their configuration. It allows you to set up things like time zones and other application settings.
00:07:29.419
A critical aspect of this file is that it calls `Rails.application.initialize`, which handles all the necessary initializations. This process includes loading Rails itself and then executing `bundle.require` with the relevant groups.
00:08:01.159
After the gems are loaded, the application class definition is evaluated, and we enter the heart of the boot process. The organization of the presentation will resemble a rollercoaster; we will dive deep into some topics and then summarize them.
00:09:05.060
Summarizing what we’ve covered so far, we establish load paths, check our gem dependencies, and then load the application itself before running the initialization process.
00:10:08.230
Rails Railtie is a class that provides extensions that allow components to hook into the boot process. It offers hooks for when the console is launched or when a runner command is executed. Rails components interact with this framework through configuration points and initializers.
00:11:16.640
For example, Active Record can declare that it wants to run certain pieces of code during initiation, allowing smoother integration with the Rails application lifecycle.
00:12:24.900
When an initializer is defined, it basically defines what happens when the application initializes. For instance, the Factory Girl initializer can set up necessary paths when the application is up and running.
00:13:15.510
Active Record defines an initializer that triggers when the console launches, setting up SQL logging and other configurations that enhance integration with Rails.
00:14:24.770
Action Dispatch shows how to define a configuration point and establish default values. Railties allow for this flexibility across components, ensuring that applications can declare their needs effectively.
00:15:40.800
Rails loads all Railties for different components, which allows the application to manage various configurations and initialization codes seamlessly. This setup makes Rails largely agnostic to many of its components.
00:16:47.970
The integration mechanism allows components to communicate effectively without tightly coupling the Rails framework to specific components. Active Record, for example, declares its needs and lets Rails know how to initiate its components during the boot process.
00:18:01.630
This loose coupling leads to a flexible architecture, whereby components such as engines can exist with predefined configurations and initializers, making them easier to use and integrate.
00:19:02.800
Engines are essentially subclasses of Railties that can encapsulate full functionalities like controllers and routes, thereby offering a way to modularize Rails applications.
00:20:38.240
By subclassing Rails Engine, you inherit various configurations and hooks to manage application initialization. For example, the engine can set its load path, define routes, and manage middleware, making it a great tool for encapsulating functionalities.
00:21:33.210
Once defined, while developing engines, you can set paths for directories and other configurations needed for them to run properly, ensuring that everything required is available when the application is booted.
00:22:08.600
Engines contain initializers and configuration points that provide further flexibility in defining behaviors needed for a modular Rails application.
00:23:17.840
Rails applications by default come with a number of initializers that are executed in a specific order, which is vital for ensuring that the necessary setups are done in the right sequence during the boot process.
00:24:55.640
The finisher group of initializers finalizes the application setup, defining routes and preparing the application to serve requests. Understanding this setup is essential to comprehend how Rails applications function.
00:26:19.020
Rails manages the loading of components carefully so that the order of the execution respects their interdependencies, which is critical when building complex applications.
00:27:32.680
The initialization process concludes with the execution of any remaining initializers. This is where all the setup that is not tied to specific components is completed.
00:28:58.620
With everything configured, the application is ready to handle requests, showing just how thoughtful and structured the Rails boot process is.
00:30:16.560
Thank you for your attention, and I hope this provides clarity around the Rails boot process.
