什么时候不应该使用Rails?

2020-08-05 15:46:12

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

应推特的要求,我们谈论了…。您什么时候不会使用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是很好的第一步。