译者 | 弯月，责编 | 屠敏
头图 | CSDN 下载自东方 IC
出品 | CSDN（ID：CSDNnews）
以下为译文：
什么场合下不适宜选择Rails？
首先，我先容一些很明显不应该利用Rails的场合，然后再磋商一些值得从技能角度去考虑的情形。
首先，最主要的是团队熟习程度。如果你的团队根本不理解Rails，而且对Rails的学习也不是特殊感兴趣，那么就不适宜选择Rails。这种情形该当很明显，但仍旧该当是第一考虑要素。
其次，当你知道其他框架更得当的时候。有时候你会特殊关注一些方面。如果你须要利用Java措辞的机器学习库，并且由于某种缘故原由你不想利用JRuby，那么就不应该选择Rails。如果你须要编写WordPress插件，则会选用PHP。有些特定的兼容性问题每每比其他所有问题都主要。
如果能够发挥Rails的优点，同时缺陷没有太大影响，则可以选用Rails。因此，下面我们来谈论优Rails的缺陷。
其余，常日Rails只能用作HTTP做事器，因此某些任务不适宜Rails。
什么场合下利用Rails属于大材小用？
不适宜利用Rails的情形包括：
非常小且不会增长的任务。如果某个做事的功能非常有限，那么利用Rails就有点大材小用。如果你不须要数据库，那么就没有必要建立数据库，对不对？如果只是一个流量非常低、不须要缓冲的中间做事器，那么利用Rails就得不偿失落。
但是，你须要谨慎处理不断增长的任务，不断扩大小型做事器的规模会带来很多麻烦。如果你的做事须要通过Web浏览器向用户供应HTTP页面，那么必须考虑将来可能须要添加的功能。仅靠最大略的办理方案远无法应对这种情形。
大略的API做事器。Rails并不善于供应支持JSON的API做事器。Rails的许多HTTP安全性都无用武之地（例如SQL注入防护、XSS防护等）。虽然对付某些数据库而言，ActiveRecord是不错的选择，但当你构建须要与浏览器对话的HTML网站时，Rails才能发挥最大上风。一样平常，在仅供机器利用的小项目中，Rails的用途不大。
与之类似，如果你须要在浏览器中渲染HTML，而Rails只卖力供应JSON数据。这时，许多Rails的安全功能和便捷功能就形同摆设了，但ActiveRecord、ActiveJob、ActionMailer等内部库仍旧不容小觑。但如果你不在做事器上渲染HTML，而且非常确定往后绝对不会，那么就不要纠结Rails了。
什么场合下利用Rails力不从心？
Rails是为小型团队和中等规模的代码库设计的。超大型团队（许多程序员）和超大型代码库（大量的掌握器、模型、代码行数）会拖垮标准的Rails运用构造。
在Ruby中，你可以编写带有非局部副浸染的代码。不论是猴子补丁，还是写入数据库，或者是在运行时创建新的类型，对付一个200人的团队来说，如果你无法信赖每个人，那么就不应该选用Ruby。有时方法太多，反而会让人头疼。有一些很好的工具可以方便在大规模团队中利用Ruby，但纵然如此，也很随意马虎碰着非常和困难。这并不是Ruby善于的领域。
大多数时候，你可以将一个大型项目分割成多个较小的项目。如果一个Rails运用过大，那么常日可以将其分割成多个运用，或者一个较薄的运用加上多个后台做事，或者一个运用加上一个微做事，等等。不论哪种办法，总有办法将其分割成小部分。Ruby非常鼓励这种做法，而我也非常赞许。
有些构造虽然不太像Rails的风格，但能很好地扩展规模。Avdi Grimm（已退休）提出的Objects on Rails便是这方面的一次考试测验，还有Hexagonalarchitecture for Rails也是，它与更古老、更通用的N-tier architecture有很多共通的地方。
但有时采取其他框架更好。一个明显的选择便是Hanami，在创建微型运用程序时它不像Rails那么快捷，但在大型团队中，它的扩展性更好。
个人而言，我还是会从Rails下手。如果只想快速开拓，然后看看市场反响，那么没有任何框架的生产力可以与Rails媲美。等到市场成功，而且可以适当降落开拓速率时，再用更坚实的框架重写就好。
另一个须要考虑的是性能问题。如果你要重写一个普通网站，那么实际上性能并不是问题，Rails在这种规模上依然能够良好地扩展。但如果面对几百倍大的网站（如B2C网站），那么有可能你的做事器用度会超过人工用度。住这种情形下，可以考虑降落工程师的事情效率，开拓效率更高的网站，以节省做事器用度。可以查看一下你的运用做事器的账单，只看看运行Rails的运用做事器就好。然后比拟一下Web工程师（即卖力编写Rails运用的人）的人为。一样平常而言，工程师的人为要远远大于做事器的用度，以是该当利用廉价的做事器韶光来换取昂贵的工程韶光。但在某个点上，天平会倾斜，此时就该当考虑提高工程师的人为，以此来降落做事器开销。
什么情形下Rails会做出错误的假设？
在谈论Rails的假设是否精确之前，我们先看看这些假设是什么。
Rails有一些大略的假设：它假设你编写的是在做事器上渲染HTML的交互运用。它假设安全性非常主要（Rails为了安全性放弃了很多），而大多数情形下你不会自己构建安全系统。它假设你有一个精英小团队来做原型的事情，或者你有一个中型团队，但有完善的指南。
Rails还假设，你乐意用技能债务来换取更快的开拓速率。换句话说，Rails的目标是快速构建运用程序。当技能实行力不是紧张考虑的风险时，这种做法很合理。例如：如果你有一个小型的创业公司，你很确定你能构建网站，但人们并不一定会买你的产品，那么你最大的风险便是市场风险。此时Rais应该是首选。你须要迅速构建。由于就算你能做出完美的产品，也可能由于非技能缘故原由（如“人们不愿意买”）而放弃。
鉴于“开拓速率优于技能债务”的信条，Rails假设你会利用大量的gems，而且只要能加快开拓速率，添加依赖也不是问题。
Rails假设你不在乎水平扩展运用做事器（即添加更多的运用做事器）。如果你能做到这一点，它就能很好地扩展。Rails假设CPU很便宜（一样平常来说这是实话）。相应地，Rails还假设数据库常日是最严重的性能瓶颈（一样平常对付Web运用程序来说，这是实情）。
Rails还假设你的运用程序须要进行一些打算或数据传输。它假设可以利用CPU，由于无论如何你都要用CPU做一些打算。
Rails不善于什么？
只管Rails善于做很多事情，但有一件事是它不善于的：垫片（shim）。
所谓“垫片”指的是自身打算量非常少，功能只是将几个其他后台做事的结果集成到一起并转发的做事器。例如一个做事器，查询两个JSON做事，并将结果大略地字符串连接。它的打算量非常小，但须要处理许多事宜。
这里的关键词是“事宜”。
Node.js支持一种分外的运用程序架构，叫做“Eventd”（事宜）编程。它仅利用非常少的资源就可以支持上千乃至百万级别的同时连接。它可以同时实现高吞吐量和低延迟。如果用在得当的地方，它的性能无人企及。
Rails完备不如Eventd编程。实在没有哪个框架能比。Ruby也有Eventd编程框架（如EventMachine、Async），但Rails完备不同。
既然Eventd这么好，为什么不在所有场合下都利用呢？由于它并不适宜统统场合。我特殊想强调的是每个要求的打算量，如果每个要求都实行很多打算，Eventd做事器就会挂掉。对付一台能处理百万连接的做事器，如果每个连接须要几百毫秒的CPU韶光，那么就大事不妙了，由于要求量太大，延迟也会非常糟糕。
换句话说，Rails和Node.js是适用于不同项目的不同工具。如果你认为“这个项目利用Rails或者Node都可以”，那么我建议你仔细想想你的项目（以及框架），直到找出明显的精确答案。这二者的用途完备不一样。
总结
如果团队不想用或者不会用，那么Rails便是缺点的选择。
如果很明显其他框架更好，或者某个须要兼容的库并不支持Rails，那么Rails便是缺点的选择。
如果不在做事器上渲染HTML，特殊是当项目非常小，并且不该用做事器时，那么Rails可能是缺点的选择。
如果不做原型类的事情（最好是在小型、高竞争力的团队内做），那么Rails便是缺点的选择。
如果开拓团队或者运用代码太大，并且无法拆分项目时，那么Rails便是缺点的选择。
如果项目须要Node.js的Eventd做事器或者EventMachine一类的功能，那么Rails便是缺点的选择。
末了，如果你只想听关于这个话题的娱乐新闻，那么这篇文章便是缺点的选择。
网友说
评论1：
我来根据我的履历说说为什么该当坚持利用Rails：
所有“轻量级Sinatra API（或者类似的API）”做事末了都会越来越像Rails运用。Rails给开拓者供应了很多遍历，除非你自己开拓一个轻量级API，否则都不会把稳到这些。例如掌握台、日志、数据库迁移、数据库连接池、rspec集成、i18n等。
没人喜好自己写项目构造。代码放在哪里？是lib？core？还是app？你以为ActiveRecord太臃肿而“无法扩展”，以是就自己编写了一个轻量级“数据映射器”模式？但不好意思没有人乐意花韶光去学习。话虽如此，Rails项目还是有一些可以随便挑选的部分，只不过不符合大家的习气。
大部分时候，开拓者会假设数据库连接池是一件很自然的事情。系统管理员不想调试你的程序。在反反复复几个星期后你就会认识到，数据库连接池是Rails供应的。而仅仅在Sinatra运用中导入activerecord再建立连接，是没有数据库连接池的。
某天，某个卖力生产环境掩护的人忘却了rake任务的名字。在运行bundle exec rake时忘却了添加-T。默认的任务是rspec。结果把生产数据库删掉了。到时你就会明白，Rails会阻挡类似的事情发生，而那些“轻量级API”不会。但是，这种教训显然还不足深刻，由于几年后类似的事情还会再发生一次。
评论2：
对我来说Rails不可或缺，你只须要15分钟就可以从零开始构建一个网站在Heroku上运行，顺便设置好SSL和域名。我特殊
说实话，纵然是JSON API加上React前真个模式，我也会用Rails。由于实在太方便了。
评论3：
我还是会选用Rails。如果你想快速开拓，然后看一看有没有人喜好，那么没有任何框架能够比得上Rails。
我有5年的RoR履历，两年sprintboot/kotlin履历，1年的Django履历。一旦设置好事情流程后，生产力方面就不会有太大差别。痛点仅在设置初始项目，以及在库版本更新时随时保持更新。
django和spring boot缺少的便是实体、掌握器和视图的命令行天生器，以及快速设置流程。
Django和spring boot须要在设置高下点功夫。Django须要settings、运用程序数组、中间件定义等。一旦这些事情都做好了，编写实体、视图和路由都非常大略。
Springboot须要坚实的文件夹构造、运用程序属性文件，还须要仔细设置好数据库迁移和日志。以是并不是那么随意马虎上手。但编写实体、掌握器、做事、视图等还是很方便的。
原文：http://codefol.io/posts/when-should-you-not-use-rails/
本文为 CSDN 翻译，转载请注明来源出处。
