ruby-on-rails - 为什么大多数 Ruby/Rack 应用程序以这种方式引导？

Question

我正在尝试找到一个书面解释来解释为什么许多 Ruby 应用程序都遵循 Rack 的这种模式:

config.ru -> loads 'environment'
'environment' -> loads 'application'
'application' -> loads 'boot'

这在 Rails 应用程序中很常见，但我在非 Rails 事物(例如 Grape API 应用程序等)中看到了相同的模式，但我不明白为什么它会按这个顺序发生。为什么环境加载应用程序而不是相反？不将应用程序+启动合并到单个文件中有什么优点？是否有关于每个“桶”中应放入哪些内容的建议/规则？

Rails 文档将所有这些文件作为 Rails 启动的一部分进行讨论，但它完全忽略了此结构提供的背后的基本原理。

Answer 1

最可能的解释是历史/传统以及 Rack 本身的工作原理。 Rack 是非常小的接口(interface)。

To use Rack, provide an "app": an object that responds to the call method, taking the environment hash as a parameter, and returning an Array with three elements:

• The HTTP response code
• A Hash of headers
• The response body, which must respond to #each

最简单的 Rack 应用程序就是:

run Proc.new { |env| ['200', {'Content-Type' => 'text/html'}, ['Hello World']] }

让我们看看这三个文件实际上做了什么:

• config/environment.rb 实际上负责启动 Rails 应用程序并为 Rack 提供它可以实际运行的东西。在简单的 Rack 应用程序中，您通常可以在此处进行大量配置并处理不同的环境。但 Rails 不再是这种情况，因为它是在框架的上游处理的。
• config/application.rb 通过需要railties 将rails 的不同部分连接在一起。它也是应用程序作者可以添加通用配置的地方。传统是，这声明了由rack运行的实际应用程序对象，而environment.rb则更加程序化。如果您从头开始构建 Rack 应用/框架，这将是您需要 /lib 文件的地方。
• config/boot.rb 使用 Bundler 加载非 Rails 依赖项 (gems)。这种情况发生得很早，以便 Rails 本身可以使用像 Nokogiri 这样的依赖项。

可以将其合并到一个文件中吗？是的。但让每个文件执行一项任务效果很好。实际上，每个文件在某个时间点确实还包含更多的代码。例如，在 Bundler 出现之前加载依赖项真是一团糟。