The Rails Boot Process
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 3 | |
| Number of Parts | 89 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/31568 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 20163 / 89
1
2
3
5
7
8
11
12
19
22
28
29
30
31
33
45
47
50
52
53
58
62
67
71
74
76
77
78
79
80
81
84
85
86
88
89
00:00
BootingRegular graphOrder (biology)Configuration spaceNumberVideo game consolePresentation of a groupContext awarenessPoint (geometry)Structural loadComputer fileGroup actionLibrary (computing)Open setSocial classRight angleAdditionString (computer science)Constraint (mathematics)Fiber bundleServer (computing)Multiplication signCartesian coordinate systemProper mapCodeEllipseIntegrated development environmentSlide ruleBitInformationElectronic program guideException handlingProgrammer (hardware)Block (periodic table)EvoluteConnectivity (graph theory)Maxima and minimaScripting languageComputer programmingDirectory serviceProcess (computing)TunisStaff (military)Instance (computer science)Asynchronous Transfer ModeBit rateNegative numberDialectGoodness of fitAreaError messageTextsystemTraffic reportingSound effectSubsetRadiusRow (database)Moment (mathematics)RandomizationTime zoneWordGenderMobile WebGame theoryDivision (mathematics)Self-organizationContent (media)Computer animation
09:56
Point (geometry)Structural loadInterface (computing)Factory (trading post)Sound effectComputer fileProcess (computing)Cartesian coordinate systemSystem callVideo game consoleBlock (periodic table)Configuration spaceConnectivity (graph theory)Series (mathematics)Design by contractRootNumberExtension (kinesiology)CodeDifferent (Kate Ryan album)HookingTime zoneSocial classEndliche ModelltheorieAsynchronous Transfer ModeBootingGroup actionDatabase transactionRollback (data management)Row (database)Rule of inferenceSoftware frameworkPattern languageDeclarative programmingINTEGRALElectronic data interchangeDefault (computer science)Category of beingInstance (computer science)NeuroinformatikRight angleQuantum stateRoboticsMetropolitan area networkBit rateMereologyDecimalCASE <Informatik>Arithmetic progressionReal numberDecision theoryLogical constantNamespaceArithmetic meanForm (programming)BitAreaMultiplication signCombinational logicGenderRoutingView (database)1 (number)Set (mathematics)RadiusComputer animation
19:43
VideoconferencingBit rateExtension (kinesiology)Right angleReplication (computing)Service (economics)Cartesian coordinate systemMereologyPoint (geometry)Set (mathematics)1 (number)Reading (process)Social classEndliche ModelltheorieRow (database)Integrated development environmentGroup actionDrop (liquid)Food energyOrder (biology)Directory serviceInstance (computer science)Figurate numberUtility softwareConfiguration spaceOntologyComputer configurationNumberSubsetInclusion mapSystem callSpeech synthesisGame controllerCASE <Informatik>Connectivity (graph theory)Quantum stateNegative numberChainExistenceFault-tolerant systemArithmetic meanTraffic reportingFrame problemRevision controlLine (geometry)Greatest elementBootstrap aggregatingStructural loadCodeLibrary (computing)Computer fileBootingBlock (periodic table)Wave packetLogical constantFiber bundleHookingSinc functionInheritance (object-oriented programming)Maxima and minimaSlide ruleSingle-precision floating-point formatComputer animation
29:29
Cartesian coordinate systemOrder (biology)NumberStructural loadTheory of relativityProduct (business)Constraint (mathematics)Fiber bundleAsynchronous Transfer ModeInterface (computing)QuicksortSoftware developerElectric generatorGroup action1 (number)Configuration spaceCASE <Informatik>Network topologyCodeTemplate (C++)Library (computing)Run time (program lifecycle phase)Point (geometry)Integrated development environmentBlock (periodic table)Computer fileDefault (computer science)SequenceSinc functionConnectivity (graph theory)Social classSlide ruleBootingRootSound effectWeb pageSet (mathematics)Software testingMereologyRight angleService (economics)Multiplication signCellular automatonGenderSemiconductor memoryConjugacy classReading (process)Row (database)Presentation of a groupQuantum stateDialectIncidence algebraFisher's exact testComputer configurationEvent horizonForm (programming)GodRule of inferenceVideoconferencingEqualiser (mathematics)Probability density functionMathematical optimizationInstance (computer science)RoutingComputer animation
39:16
Computer animation
Transcript: English(auto-generated)
00:03
Good afternoon. We are going to see a talk about the Rails boot process and I would like to explain before the goals of this talk
00:24
So, in this talk we are going to see a few things related to this topic. For instance, if you open the config directory there are a number of files that we normally never touch that are generated, like this config boot rb,
00:41
config environment rb. So, we are going to see what they do, okay? Then, Rails components, in general, can work independently of Rails. So, ActiveSupport, for instance,
01:01
is a library that you know you can use in a Ruby script, you know, that is not running inside the Rails application. Also, for instance, you can use ActiveRecord outside Rails. You can have like a regular Ruby script using ActiveRecord connecting to the database, everything, you know, you have everything.
01:21
But somehow, magically, you launch a Rails application and all these independent components are somehow organized for you and seamlessly, you use them, you know, and there's nothing that the programmer has to do to get these things working together.
01:43
And we are going to see how that works. And, you know, the final goal is to understand more or less what happens when, okay? I say more or less because there's a lot happening, but we are going to have a good sense of what happens when.
02:02
And for this talk, we are going to have to take into account a few things. First, the approach of the talk is thought for Rails programmers, alright? So, for instance, it's not going to be like, you know, a walkthrough of, you know, of code and code and code and see the runepath of these things.
02:22
So, we are going to see code, but it's not a walkthrough. So, with this talk, I have tried to explain what I would like to know as a Rails programmer about the boot process, okay?
02:40
And it is something that I would like an init guide to cover, you know? That kind of information. In the boot process, we have Railties and we have engines, but this is not a talk about Railties and engines. We are going to see what they are, but that's a topic for the whole talk, okay?
03:04
So, we are going to see only what is needed for this talk about Railties and engines. Therefore, we are going to see some code snippets, but they are going to be like heavily, heavily edited. So, I have not tried, even tried,
03:22
that you understand, so that the slides makes clear this has been edited, you know, with ellipses or something like that. We put like a big warning and, in general, the code we are going to see, if you open the real file, is going to have more stuff, okay? But there's a lot going on and I tried to select
03:42
and, you know, uncut everything out that was not relevant to the topic we are talking about. And finally, we are going to ignore Spring, you know? So, the boot process, assuming that, no, no, no, no, this is the boot process, you know?
04:01
The vanilla thing, okay, without additions. All right. So, normally when you think about booting Rails, you have a server in mind, okay? You launch the application, you launch the server, you are able to serve requests and everything.
04:22
But there are more things that boot Rails. So, for instance, if you run the console, you know that somehow you have everything in the application available in the console, right? Also, runner, if you run, you know, if you pass runner a string or a file name,
04:42
it gets executed in the context of the application. So, somehow, the application has been boot for, you know, in order to run these commands. Runner, indeed, is a command that I love. I believe I run this command every day. So, it allows you to run something quickly. Instead of launching the console
05:01
and then Control-D and that kind of thing, you just, you know, runner something, and indeed, to understand the Rails initialization, runner one, which is execute the program that has a literal one, you know? It's something that I do often, you know? So, that's the minimum thing, the minimum thing Rails runner one,
05:22
the minimum thing that, you know, loads what it has to load, does what it has to do, and then there's no more shade effects, except evolution one, which is not allowed. And also, in some Rails tasks, you know that you have also the environment load. So, booting the application means being ready
05:42
to serve all these kind of things. All right, so let's open binrails, okay? This is a file that is generated but in any, at least, modern Rails application. And we have here config boot,
06:03
we load config boot, and then it doesn't require something, okay? If you open binrake, you will see that it loads config boot and then does stuff related to rake, okay? So, these both files start loading config boot.
06:25
That's the first thing. And if you open config boot, you will see that it's basically doing bundle setup, okay? Bundle setup configures the load paths,
06:40
so the application is able to require the gems that are in the gem file, with all the constraints and everything, and is not able to load gems that are outside that thing, okay? So, bundle setup tweaks load path, and I don't know, all is needed, so that is going to work.
07:05
Then, if you open config rule, which is what you execute when you launch a server, you will see that it requires config environment, okay? And then does something. Config environment is another important file.
07:22
It loads application, and this is config application rb, which is the first file we normally, you know, working as a programmer, that's kind of the first thing, you know? Config application rb is where stuff starts, where you can config, I don't know, time zone,
07:41
that kind of stuff, okay? So, that's the file that is being referenced here. And then, very important, it runs Rails application initialize, and this is the magic. So, initialize, this method, is the one that runs all the initializations. Up to now, we are like, setting things up, you know, to be able to do this.
08:04
And this is config application rb, which loads Rails all, and then executes bundle require with the groups that are relevant to that execution, okay? So, Rails all, we are not going to see,
08:21
we are going to see Rails all later, okay? Forget about it for a moment, but the point here is that we are doing bundle require. At this point, is when the gem dependencies are loaded, okay? Unless you opt out, okay? At this point, and after that, we evaluate the class that defines
08:42
the application itself, which is, you know, this thing that is named after, you know, what you passed to the new command, that kind of thing. Okay, so the presentation is organized in a few blocks.
09:03
And it's going to be a bit like a roller coaster, okay? So, we are going to dive a little bit in something, and then a little bit up, doing some summaries, okay? So, this is the summary of what we have seen up to this point.
09:22
So, define load paths. We have the gems dependencies ready. Then load Rails all, which is something that is going to be seen later. Then we actually load the dependencies, define application class, run initialize.
09:42
That's like the script, no? That's the order in which things run at this point. And it's initialize that does, you know, the proper Rails boot process, okay?
10:01
All right, Rails Railtie. So, Rails Railtie is a class that provides a number of things so that extensions and, you know, are able to hook into this process.
10:21
For instance, it provides hooks to run code when you launch a console, when you launch the runner command, you know? So, you can say, as a gem, you can say, hey, if I am loaded in a Rails application and the console is launched, please call this code, okay?
10:40
And we may have like, you know, a series of blocks like this that are scheduled to run at that point. Then you have the ability to define custom configuration points, okay? So, when you see like, for instance, config dot something, config dot active record dot something,
11:01
you know, a Railtie we're going to see later that active record is a Railtie, allows you to define configuration points so that applications are able to, you know, to express the configuration they want. And also, very important, they have the ability to declare code to be executed during boot.
11:24
So, these are called initializers, okay? So, hooks, configuration points, and the ability to declare. So, Railties can declare that I want to run something when the initialization happens,
11:42
which is something I don't know, okay? Railties are defined by subclassing this class, this very class, and Rails knows which Railties are defined, because there's an inherited hook, you know, that when Railtie is subclasses,
12:01
there's an inherited hook that say, hey, I have been subclasses, and that by definition is a Railtie, okay? Well, there's a technical thing about some special subclasses that I ignored, but that's the idea. So, let's see an example, okay? So, this is, for instance, a Railtie of factory gal. And this initializer thing with a block is,
12:25
factory gal is declaring. When the application is initialized, and I don't know when that is, you know, but when it happens, you've got to run this code. So, for instance, the factory gal at this point
12:42
knows that Rails root is already defined, okay? That's a contract. You know you can assume that, okay? And in this case, factory gal is setting up some factory paths or something like that, okay? So, the way factory gal, so factory gal needs to define some paths
13:00
that depend on the Rails application, and the way to do that in an integrated way with Rails is to define a Railtie and say, okay, when you are booting, call me, and I will configure myself, all right? So, Rails components are integrated into the framework using Railties.
13:22
For instance, this is the Railtie of ActiveRecord. ActiveRecord defines a Railtie to integrate into the framework. In this case, for instance, this is an example. This is the hook that tells Rails to run this code
13:40
if the console is launched, okay? So, if the console is launched, if it's launched in sandbox mode, which is a mode that starts a transaction and rollbacks a transaction when the session is over, okay? Load some code. I have not copied it here, okay? Load whatever you need to support this thing,
14:01
and for instance, then you know that recently in the console, you get the SQL log in there, so there's code that says, okay, unlock to standard error, all right? So, that's the way ActiveRecord integrates into Rails by defining a Railtie that does this
14:21
and does a lot of other things, all right? Okay, for instance, this is from action dispatch, and we are seeing here an example of configuration. We saw before an example of hooking into the console. Now we see an example with configuration. So, for instance, this is the way action dispatch
14:43
defines a configuration point, call it TLD underscore length, and it gives this configuration point a default, which is one, okay? This is from active support, and this is another initializer.
15:02
We saw an initializer for factory girl. We are now seeing an initializer for active support, and we do not need to understand this code, but it's basically taking the timezone that the application has configured and setting whatever active support needs to set up
15:21
to take into account that configuration point. Okay, so that's what Rails All does. Rails All is just, you know, it just loads all the Railties of the different components in Rails.
15:41
So, application Airbnb loads this file. This file is just looping and loads everything, all right? And as a side effect of loading these things, we have first that Rails knows that Railtie has been suppressed,
16:02
so we are able to list the Railties that have been load, and also, as a side effect of loading this, we have the configuration points, the declarations of the initializer, so it's like a setup, okay? And that's the way the components work seamlessly
16:24
in a Rails application. So, the application, in reality, well, as a rule of thumb, let's say, maybe it's not 7%, you know, in all cases, but as a rule of thumb, this is, I don't know,
16:41
I like very much this design. So, Rails is not coupled to the components. Rails is kind of agnostic to most of them, all right? So, Rails does not have in the initialization process anything that, you know, that hardcodes the stuff,
17:02
you know, to integrate the components. No, no, no, it goes the other way around. So, the Railties are, you know, loaded, and the configuration points are the interface between Rails and these components, okay? So, ActiveRecord just loads and say,
17:21
hey, call me in the console, please run this initializer, blah, blah, blah, blah. Okay, and the same for the rest of Rails components. And are the Railties, so are the components that know that they are living in a pattern application?
17:41
Okay, that's the way they integrate. So, Rails does not hardcode in general anything about ActiveRecord, that kind of thing. Rails just exposes a number of configuration points, ActiveRecord loads, takes the configuration points that it needs to set up itself,
18:01
and, you know, you're set, okay? That's the idea. So, a vanilla Rails application has 15 Railties, which are these ones, okay? So, you see, everyone that needs to integrate with all this process has to define a Railtie.
18:24
All right, next block, lazy loading. So, in general, so, example of heavily edited code, this is ActiveRecord, RV, which has a lot of things, okay? All right, so, in general, if you open
18:42
like the root file of the Rails components, you will see a lot of auto loads like this one, okay? This is the auto load of Ruby. Well, yeah, so, Rails redefines because auto load in Ruby needs, you know, the constant, and then it needs a path, all right?
19:01
But when you follow naming conventions for the files, and you write this thing three times, so the reaction is to write something that automates this using the conventions. So, model is that, this is the Ruby auto load, not the Rails auto load of constants, okay? So, in general, when you boot,
19:21
Rails tries to be as lazy as possible loading things, so you have the minimum things to do when you boot. One of them is setting auto loads for, you know, this is the ActiveRecord is the namespace, so ActiveRecord base, ActiveRecord, I don't know, whatever, is going to be auto load.
19:42
So, it's not going to be ActiveRecord base, it's not going to be required on boot. It's going to be required when it's needed, you know? And that's thanks to auto load. So, since things are going to be loaded only when needed, and there's code that needs to know,
20:01
hey, have you load already ActiveRecord? For instance, to include something in ActiveRecord base or whatever. There's this utility which is ActiveSupport on load. So, for instance, in the ActiveRecord Rail tie, we have to set up the logger of ActiveRecord,
20:22
and the initializer does not go and straight away assign the logger, because the way to do this orderly is, you declare that when ActiveRecord is load, then please set the logger with the block
20:42
that I am passing here, okay? So, that's the way to defer as much as possible things in order to have a boot process as lightweight as possible. And at the end of ActiveRecord base, at the end of ActiveRecord base,
21:01
which is what ActiveRecord considers to be, you know, loading ActiveRecord, no, by definition is evaluating this file, it says room load hooks for ActiveRecord, okay? So, when this file is evaluated,
21:20
all the, you know, the class is defined, and at the bottom of the file, you have this line, and then everything that was, you know, scheduled to be run when ActiveRecord loads is going to be run at this point. Okay, next block is Rails engine.
21:43
Rails engine is a subclass of Rail ties, okay? Of Rails Rail tie. They are defined as well, so Rail ties were defined by subclassing Rails Rail tie, and engines are defined by subclassing Rails engine.
22:01
So, it's the same kind of thing, okay? And what is an engine? So, this would be like one, two, three talks, but just, you know, so just to get the idea of what it is, first inherits everything from Rails Rail tie, so all we saw before about console, runner, you know, hooks,
22:21
initializers, config points, that's all available here, but it's like a superset. You can do more things with an engine. So, for instance, you know, you can define controllers, models, that kind of thing. You have initializers as well, assets, you know, a bunch of things. So, it's closer to, like, you know,
22:42
unless you are able to define like a subset of an application, that's the idea for an engine, okay? Um, so engines have predefined some configuration points and also some initializers, all right? So, just by subclassing engine,
23:01
you got some configuration and some initializers for starters. So, this is the one that are inherited. So, when you define an engine, subclassing Rails engine, you get this kind of thing. So, you're going to set the load path of the engine, okay?
23:20
So, adding your own lib directory or whatever, you know, to app models, whatever, to the load path that is already set. Auto load path, routing paths, locales, a number of things, okay? So, it is not important to follow every single step of this. You know, it's maybe too detailed,
23:41
but just, you know, to give an idea of the kind of things that you inherit from an engine, build paths, load environment config is, these are initializers. This is the initializer that runs whatever you have in config environments, development, config environments,
24:01
production, rebE, whatever. And then some other paths. Then you load config initializers, all right? This order. And then there's a technical hook engine's black point that says, at this point, you have already run a number of things,
24:21
and if you are interested in hooking into this, you can, all right? So, initializers, by default, go like in chain, but you can say, this has to run before this other initializer, or this has to run after that one, and there are a number of technical points in order to be able to do that.
24:43
And a vanilla Rails application, which is like Rails new, you know? What do we get with Rails new? There are four engines, these four, okay? Okay, action cable is an engine, it has an engine, so the rest of Rails components have Railties, because with a Railtie, it's enough,
25:02
what they have to do on boot. And action cable has some assets, and that's the reason it is an engine. All right, and we are arriving to Rails application, which is a subclass of engine, so look at this hierarchy. So, the base thing is a Railtie,
25:21
then we have an engine, and an application is a subclass of engines. So, you know, the application is like a particular case of all this design, okay? Beautiful, I think it's beautiful. All right, so they are defined by subclassing, and that's what you do in config application Airbnb.
25:42
You see, if you remember, you have your application subclassing Rails application, that's exactly what that file is doing. So, the application is indeed is a singleton, you know, there's just one instance of that class, and you can access that instance
26:02
using Rails.application, which is a method. And when the singleton is instantiated, you get a hook, call it before configuration. That's also just something that is fired, and if you're in a Railtie, for instance, you say config.before configuration,
26:25
execute something, is going to be executed at this point, which is just when the application is just, you know, it got instantiated, you get this code called. Okay, so application execute four groups
26:42
of initializers, four groups. It's organized this way. First, you have the ones inherited from Rails engine. Okay, Rails engine have some preconfigured ones, so those ones you inherit, therefore, they are going to be executed. Then, there's a bootstrap group
27:03
that does like super basic things, like setting up paths and that kind of thing. Then, we have the initializers of all the Railties and engines that the application has load, okay? And the way this is load is because we have a bundle require in config application.
27:22
So, if you have an extension, a gem or something implementing a Railtie or an engine, so what happens is that when bundle require loads that gem, that gem, you know, at that point, defines the Railtie or the engine so that the application knows
27:41
about the existence of this thing. And then, there's a finishes group that does some training stuff. So, the bootstrap group, for instance, the first one is a technical hoop as well.
28:01
Then, for instance, we load active support. So, active support, that's not something optional. The whole Rails uses active support, okay? So, straight away, this one is hard code. This one is loaded. Yeah, so this loads active support all,
28:23
which brings you everything in active support, unless there's a configuration point, which is config active support bare, which says instead of loading everything, just load whatever the application, I mean, whatever Rails needs, you know, to run.
28:42
And this slide means that we are finishing. No? All right, I saw a change. Okay, okay, fine. Yeah, so you are able to load as, you know, the minimum of active support, okay?
29:02
That said, I have never seen this one used, but we have it there. Then, eager load, you initialize the logger. This is the bootstrap group, okay? So, you initialize the logger, the cache, the way constant autoloading loads things,
29:24
which can be load or require, depending on the environment or configuration. And then, there's a before initialize hook, the details, too much details, okay? There are a number of things that are going on, just having a look.
29:40
And then, Railties and Engines in a vanilla Rails application have 94 initializers declared, okay? It's too much. So, then we have the finisher group, okay? These things, more or less, you can think that they run more or less in order,
30:01
except that the before and after things that are, you know, when you declare an utilization, you can say before this and after this, you know, unless you have defined something, you can more or less think that they go in order, okay? So, yeah, a number of things. The finisher group does a number of things.
30:24
It configures lib templates in case generators need to load things from here. Yeah, this second one is technical. Then, this one is defining, you know that if you go in development mode to Rails info,
30:40
you get some pages there, and if you go to the home, you get this new shiny thing, you know, in Rails 5? So, the way that works, if you go to config-roots-rb, that's not in config-roots-rb, so how is that served? All right, so the roots are defined here, those ones are defined here.
31:00
You build the middleware stack at this point, so we are kind of already late, okay? You have to think we are already, most of the things are done at this point. Well, you define main app, which is something for engines, doesn't matter. To prepare blocks, important, these are blocks
31:21
that are on certain points of the run time. And eager load, this is important, by default in production, you eager load the application, and then there's another technical hook, which is the finisher hook, that fires another event, which is after initialize, in case you have to do
31:42
something after this has run. All right, and a number of things that are too detailed, maybe, well, the second one loads the roots, this one is important, okay? But there are a number of things in this finisher group going on. Okay, so, once everything has been declared,
32:05
and we have everything load, you know, there's a topological sort going on here. So, an etlizer have an after, before, topological sort, if someone does not know. Basically, if you have things that have a relative order declared,
32:25
like, I have to run at some point, but make sure it's before that thing, or, I have to run at some point, but make sure it's after that other thing, okay? So, a topological sort is getting this linear in a way that respects these relative constraints, okay?
32:44
So, if you need to run before that thing, you are guaranteed that you are going to run before that thing, okay? Maybe not immediately before, it doesn't matter. So, the constraint is relative, okay?
33:01
So, maybe not just before, maybe to before, I don't know, depends on the other things that have set that need to be run before that hook, okay? So, that's the idea. In any case, we order the etlizers to be run the way they have declared to be run.
33:21
So, at this SHA-1, we have 124 etlizers. There's a lot going on, okay? Because everything, you know, this is designed so that everything that needs to happen at boot is going to be generally happening in an etlizer.
33:40
So, there's a lot of things, 124, and I have listed all of them, so if you get then a PDF or we see the video, we have them at least, you know, as a reference. This is not like public interface, this is not something Rails is telling you,
34:01
these are going to exist, you can assume that all of these 124 are going to exist in other releases or something like that, so, you know? But anyway, just for the sake of the presentation, these are the ones, I am just going to pass the slides because, you know, there's no point in going one by one,
34:23
but, you know, you see we have setting load paths here, then auto load paths, you know, and there are like, all right? So, yeah, so what I want to say here
34:42
is just that you are aware that all of these initializers are defined and all of these things are running, okay?
35:03
Okay, so we've seen, like, a number of things, and there's too much to get, like, what, which is the whole picture. So, from all this, I've selected what I think I would like to have clear as a Rails programmer.
35:22
Okay, so you've seen there's a lot of things going on, so this is the summary of the summaries, like, you know, the essential things that we need to know. All right, summary of the summary. We go to the beginning of the presentation, okay?
35:40
With booter being the kind of thing. So, first, we define the load paths, which is bundle setup. So we have the gems, you know, the ones that we want to be available and not the ones we do not want to have available. Then, we load the rail ties,
36:00
and this side effect defines all these configuration points of this initializer, you know, active record, and all the Rails components. After that, we load the gem dependencies with bundle required. Then, the application class itself is evaluated, okay?
36:21
The definition of the application class itself is evaluated. And then, there's a bunch of paths, like auto load paths, you know, load paths, stuff. All right, after that, and this is important, at this point, we load config environments,
36:42
development rb, production rb, whatever, okay? And this is why the configuration in these files takes precedence over the one in config application rb. Simply because it runs after it, okay? So if you say foo equals one in application rb, and since after that, you run config environments,
37:04
development rb, for instance, and you say foo equals two, so it takes precedence just because it's, you know, evaluated, you know, later, and that's the one that remains. After that, the initializers in the application engines
37:21
or whatever, are run, okay? So first application, then development rb, production rb, whatever. After that, config initializers. These ones are executed in lexicographic order, and after that, if needed, the application is eager loaded.
37:41
That happens in production mode, by default. Well, another thing, so, yeah, parenthesis. So we've seen that Railties integrate into Rails via configuration points, all right? And in general, something curious as well is that in Rails in general, in general, maybe if you do a grep, maybe you find a counter example,
38:01
but in general, the Rails code base is not full of, if development question mark, if production question mark, no, no, no, the interface is, we have parameterized Rails using configuration points, okay? And when you generate a new application,
38:23
development rb, test rb, production rb, whatever, sets sensible defaults for that environment. And then, Rails just checks this configuration, all right? So it's not that in production, you do something.
38:41
It's that in production, the default generated in production has a value that makes that happen, okay? Right, so we run this once, eager load, we load the roots, and if we were running a command, then the hooks of the command are root, okay? So this is like the most important sequence of things
39:04
that we have to remember, all right? And that's it, all right, thank you. Thank you.