什么时候不应该使用Rails？

我最近又上了杰森·斯威特的播客。他是个很棒的面试官，我和他在一起总是很开心。

应推特的要求，我们谈论了…。您什么时候不会使用Rails？这是个很好的问题。

要获得娱乐版本，请收听播客。为了更全面地了解事实，我写下了这篇文章。

我将从几个您不会使用Rails的简单、明显的时刻开始，然后我将谈论一些技术上有趣的时刻。

首先，也是最重要的，是团队熟悉度。如果您的团队还不了解Rails，并且对学习它不是特别感兴趣，那么Rails是错误的选择。这一点应该是显而易见的，但它仍然值得首先买单。

第二，当你知道其他框架更适合的时候。我将在下面更多地讨论这是什么时候。但有时，你有一种特别的担忧，它压倒了一切。如果您需要使用Java语言机器学习库，并且出于某种原因不想使用JRuby，那么Rails不是您的框架。通常，有一个特定的兼容性问题凌驾于所有其他问题之上。

你也可以把它想成：在Rails的优点存在而缺点不存在的地方使用它，所以我们也会讨论它的优点和缺点。

另外：您通常只使用Rails作为HTTP服务器，所以有些任务根本不是Rails形状的。

不会增长的非常小的任务：如果服务器做的很少，Rails通常就太多了。不去碰数据库吗？那么数据库设置对您没有帮助，是吗？仅仅是一台没有缓存的小型低流量中间服务器？很多Rails带来的麻烦超过了它的价值。

不过，要小心处理不断增长的任务--让一台很小的服务器扩展以做更多事情可能会很难看。如果您已经在使用Web浏览器向人类提供HTTP页面，请考虑稍后可能需要向其添加功能。从“开始”这个词来看，这样的东西已经相当大了。

当它“仅仅”是一个API服务器时：Rails可以提供的API服务器更少，它可以通过网络与JSON通信。在这种情况下，它的很多HTTP安全性都无关紧要(例如，SQL注入保护、XSS预防)。虽然ActiveRecord适用于某些数据库用例，但当您构建与浏览器对话的HTML站点时，Rails确实大放异彩。主要使用机器读取的结构化格式的非常小的项目通常较少从Rails中获得。

与此相关的是，当您在进行浏览器内呈现时，Rails“只是”为JSON服务。这是一种奇怪的中间案件。许多Rails安全性和便利性函数不再对您有帮助，但是您仍然在做内部库(ActiveRecord、ActiveJob、ActionMailer)非常有用的事情。但是，如果您永远不会在服务器上呈现HTML，并且您非常确定永远不会，那么Rails对您的帮助可能会更小。

Rails也是为小型团队和中型代码库设计的。庞大的团队(大量程序员)或庞大的代码库(大量控制器、模型和/或代码行)往往会拖累标准的rails-app结构。

Ruby允许很多非本地效果。无论是monkeypatch、写入数据库还是在运行时创建新类型，Ruby都不是为200名程序员组成的团队设计的，因为您不信任他们中的一些人。他们有太多的方法给你带来麻烦。您可以使用好的工具将Ruby扩展到更大的团队，但即使这样也会有例外和困难。这并不是Ruby真正喜欢的地方。

在大多数情况下，您可以将一个大项目分成几个较小的项目。如果一个Rails应用程序太大，您通常可以将其分成多个应用程序，或者包含更多后端服务的较薄的应用程序，或者一个应用程序和一个单独的微服务，即…。不管怎样，通常会有一种方法来分离出较小的碎片。鲁比强烈鼓励这样做，我也是。

还有一些不太完善的Rails结构可以更好地扩展。Avdi Grimm(现已退休)的OBJECTS on Rails就是朝这个方向发展的一次尝试，Rails的六角形架构也是如此，而后者又与更老、更通用的N层架构有很多共同之处。

但是在某种程度上，您可能想要考虑一个不同的框架。Hanami是一个显而易见的选择，在开发一个小应用时，它的设计不像Rails那么快和灵活，但是如果你想在更多贡献者的情况下使用相同的代码，那么它的伸缩性更好。

就我个人而言，我仍然会从Rails开始。如果你正在快速构建一些东西，看看是否有人关心，我知道没有一个框架能接近它的生产力。等待重写(在更严格的框架中)，直到您成功，并且您可以承受对开发速度的拖累。

这里的另一个担忧可能是性能。如果您正在重写一个已经与当前Basecamp…一样大的项目。那你的表现就没问题了。对于他们来说，Rails的伸缩性仍然很好。但是，如果您看到的东西要大一百倍(根据定义，它指的是B2C，而不是B2B)，那么您可能会遇到这样一种情况，即您的服务器成本远远高于您的工程人员工资。在这种情况下，降低工程师的速度以降低服务器成本是有意义的。要检查这一点，请查看运行Rails的应用程序服务器的EC2或等效成本是多少。检查你的工资单，只给网络工程师，他们是用Rails编写的。通常情况下，工程工资单要大得多，你应该坚持用廉价的机器时间来换取昂贵的工程时间。但在某一时刻，天平可能会倾斜，您应该考虑提高您的工程师工资以降低服务器成本。

在检查Rails的假设是否适合您之前，我们应该先看看这些假设到底是什么。

在你相信我的话之前，我建议把David Heinemeier Hansson的话当做Rails Doctrine的形式。这是一份很棒的文件，涵盖了很多领域。

实际上，如果您想更好地理解为什么Rails对于大型、低信任的团队来说并不令人惊讶，您应该多次阅读Rails Doctrine中的“Provide Sharp Knves”。许多Rails的权衡完全是设计出来的。

Rails还有一些更简单的假设：它假设您正在使用服务器呈现的HTML编写交互式应用程序。它假定安全性至关重要(Rails为安全性付出了很多代价)，但在大多数情况下，您不想构建自己的自定义安全系统。它假设你要么有一个做原型工作的优秀的小团队(“提供尖刀”)，要么你有一个可能平庸的团队，需要强大的内置指导(“菜单是Omakase”)。

Rails还假设您希望以技术债务为代价获得较高的开发速度。换句话说，它是为快速建造而设计的。当技术执行不是您最大的风险时，这是有意义的。例如：如果你正在建立一家小型初创公司，你非常确定你可以建立网站，但人们可能不会购买你的产品，那么你就受到市场风险的支配。这就是Rails最完美的时候。你想要快速建造。即使你建造得很完美，你也很可能因为非技术原因而不得不扔掉结果，比如“人们不想买。”

如果Eventent要好得多，为什么我们不把它用在所有的东西上呢？因为它不是万能的。我强调每个请求的计算，因为如果您试图让一个事件服务器执行非常多的每个请求的计算，它将会崩溃和死亡。如果每个连接使用100毫秒的CPU时间结束，那么让一台服务器处理一百万个连接是不好的-这简直是太多的连接，并且延迟将是可怕的。

换句话说，对于不同的项目，Rails和Node.js是不同的工具。如果您在想，“我应该使用Rails或Node来解决这个问题”，我建议您更深入地研究您的项目(和/或您的框架)，直到很明显哪一个是正确的答案。他们做不同的事情。

你看，我只是滚动到摘要的底部，然后在Reddit上批评它。

如果您的团队不想使用Rails或不知道如何使用，那么Rails是错误的选择。

如果不同的框架特别好，或者您有一个特定的库需要与之兼容，而该库对Rails不友好，则Rails是错误的选择。

如果您不在服务器上呈现HTML，尤其是如果您的项目非常小和/或不使用数据库，那么Rails可能是错误的选择。

Rails是错误的选择，因为您不是在做原型风格的工作，最好是在一个小的、能力很强的团队中工作。

如果您的开发团队或应用程序代码太大，并且无法细分项目，则Rails是错误的选择。

如果您的项目需要像Node.js或EventMachine这样的事件服务器，那么Rails是错误的选择。

如果你宁愿听一个关于同一主题的有趣的播客，那么这篇文章是错误的选择。

如果您想知道什么时候Rails是正确的选择，Rails Doctrine是很好的第一步。