11

我想用 Ruby 构建一个 Web 应用程序，但我不知道是否可以在不使用框架的情况下这样做。我不知道为什么大多数 Ruby 开发人员使用像 Rails 或 Sinatra 这样的框架。

如何设置不基于现有框架的 Ruby Web 应用程序？

4

1 回答 1

83

是否可以在不使用框架的情况下用 ruby​​ 制作 Web 应用程序？

太长; 没读

是的，这绝对是可能的。大多数 Ruby 框架都是在其他中间件库（例如 Web 服务器接口）之上使用纯 Ruby 构建的。

红宝石和网络

Ruby 是一种通用语言；因此它不是专门为 Web 开发而设计的。例如，PHP 是一种用于创建 Web 应用程序的语言。在 Ruby 中，您将需要一些库来正确处理 HTTP 标头和 Web 特定元素。

例如，在 Python（另一种通用编程语言）中，我们有一个标准的 Web 服务器接口规范，称为WSGI（Web 服务器网关接口）。每个实现 WSGI 规范的服务器都称为WSGI-compatible。并且任何 WSGI 兼容的服务器都可以以相同的方式运行相同的 WSGI Python 脚本。

为什么我在谈到 Ruby 时要告诉你这个？因为 Ruby 与 WSGI 有一个非常相似的概念，但可能的例外是它还不是一个标准。它的名字是Rack，它提供了一个接口来处理你不想自己处理的常见的低级 HTTP/Server 东西，这样我们就可以像使用 PHP 一样使用 Ruby 。

Ruby、Rack 和 Apache

让我们举一个现实生活中的例子：Apache。Apache 是最常见的 Web 服务器之一。PHP 如何与 Apache 一起工作？与mod_php. Python WSGI 兼容的应用程序如何与 Apache 一起工作？与mod_wsgi. Ruby Rack 兼容的应用程序如何与 Apache 一起工作？与mod_rack. 你能看到这里的模式吗？Web 服务器需要知道如何正确地将您的应用程序链接到请求/响应 Web 上下文。

机架示例

在这个抽象的演讲中不做进一步讨论，让我们专注于一个例子：

class HelloWorld
    def call(env)
        [200, {"Content-Type" => "text/plain"}, ["Hello world!"]]
    end
end

此示例由 Rack 网站提供，它解释了 Rack 兼容脚本如何运行：

  • 您安装rack在您的网络服务器上（您会在 Google 上找到大量针对您的网络服务器的教程）
  • config.ru您在根文件夹中创建一个文件（.ru主要是Ruby）
  • 你粘贴那个脚本
  • 你用run方法运行它

等等，我们有一个 Web 服务器界面。哈希包含来自当前请求的env环境变量，您返回的数组包含 3 个组件：

  1. 响应状态。200 代表“一切正常”。404 代表“未找到”。等等。
  2. HTTP 标头。这些描述了响应主体。它的长度。它的内容。等等。
  3. 响应体。这包含应用程序的实际输出。HTML、JSON、XML、HXML、简单文本……随便什么。

例如，在 PHP 中，所有这些都是自动完成的。当您执行echo "Hello";此操作时，PHP 解释器会为您生成响应状态和标头。

关于替代品的说明

您可以随心所欲地挖掘这个领域，但下面列出的大多数技术要么已被弃用，要么社区强烈反对使用它们。

在网络的最初几年，有一个通用接口用于在服务器端运行 Perl、Python、Ruby、C 脚本：CGI或通用网关接口。这是一个几乎可以被任何编程语言使用的接口，但它通常被认为很慢。

一些人认为通过使其更快来恢复这个界面。从那，你猜怎么着，出现了FCGI或 FastCGI。这项技术的使用频率超出了您的想象。一些 PHP 脚本有时会转换为 FCGI 脚本，以使它们运行得更快。我不想进一步讨论这个话题，因为那里还有很多其他参考资料。

最后，您可以创建自己的 Web 服务器。实际上，您不必为了使用 Ruby 而使用 Ruby 创建 Web 服务器。从理论上讲，Web 服务器很简单：

  1. 监听一个端口（大部分时间是 80）直到有请求进来
  2. 处理请求
  3. 输出响应
  4. 转到 1

在现实生活环境中，您不希望自己为生产网站实现 Web 服务器。所以我绝对不鼓励这样做。

如果是，为什么大多数 ruby​​ Web 开发人员都选择框架？

专业人士

框架的目的是使您的开发快速。如果你有最后期限，你不想处理低级的东西，你会喜欢一个framework build -blog命令，它可以为你管理尽可能多的无聊的事情，让你专注于真正的应用程序设计。

框架通常是开源的，并且拥有庞大的社区，这有助于使框架更快地变得更好。您可以很容易地理解，10.000 对眼睛看到的代码中的错误比您自己编写的代码要快 10.000 倍。

缺点

有些框架可能对您的需求来说太大了，而另一些框架可能太小了。在 Ruby 上下文中，有巨大的 Rails 和它的小兄弟 Sinatra。一个很大，另一个很小，真的不碍事。有时你想要介于两者之间的东西。

框架通常非常通用。这意味着您必须配置对您的上下文来说似乎很明显的东西。

框架包含的代码比您需要的多。这是一个你可以自己推断的事实。这通常意味着更多的复杂性和更多的错误（尽管这被他们周围的庞大社区所弥补）。

于 2013-04-08T13:15:40.217 回答