抨击Ruby on Rails神话

Question

我正在为我工​​作的IT公司的客户开发一个项目,我确信Rails非常适合它.我在第二天左右开会,恐怕我会被"为什么Rails"轰炸？类型问题,毫无疑问,一大堆修辞如"Rails不扩展","Rails只是一个CMS"以及人们似乎对Ruby on Rails的其他千个神话.

我们似乎都有关于Rails如何不扩展的论点,它很难部署,或者它会在任何特定时刻在你手中爆炸.对于我们这些每天使用Rails的人来说,我们知道它就像任何其他语言或框架一样.似乎有很多关于RoR的错误信息,并且通常Rails得到一个糟糕的包装.为了帮助我参加这次会议,我希望能够编制一份神话清单 - 也许是每个答案中的一个神话 - 我们可以投票选出我们之前听过的神话 - 消除恐惧,不确定性和怀疑,这往往会掩盖真相轨.

经过一些谷歌搜索我发现这篇博文,这正是我想在这里整理的那种东西.正如David Heinemeier Hansson在帖子中所说:

所以我认为现在是时候将这些记录直接放在一些毫无根据的恐惧,不确定性和疑虑上.我当时会经历这些神话,并向你展示他们为什么不是真的.

这并不是说服你应该使用Rails.只有你可以做出这个选择.但要向您提供事实,以便您做出明智的决定.一个不是在许多神话中浮现的.

让我们澄清一下!

Answer 1

神话: "Ruby on Rails无法扩展"

胸围:这不是一个具体的,可回答的问题.请澄清.

说任何技术"无法扩展"听起来都非常专业且非常有企业 - 但这不是一个明确的问题.这只是解雇未知/未经证实的懒惰方式我要求澄清:

"你的'尺度'究竟是什么意思？你现在如何测量它？"

这可能意味着:

• 最多用户会话
• 给定负载的平均响应时间
• 在固定时间内每台服务器的给定并发方案的吞吐量.
• ...组织项目的困难,以便大型开发团队可以开展工作.

有很多方法可以处理"规模",但在你知道你正在处理哪一个之前,并不总是明白该怎么做.

有大量基于红宝石的解决方案,包括

• 缓存HTML的片段
• 跨多个数据库分片应用程序
• 预先计算在用户之间共享的工作
• 将大量的视图渲染工作推送到AJAX/Javascript域中,以便它在客户端上发生
• 更有效地使用前端Web服务器
• 只需使用更多硬件(即开发人员时间昂贵且硬件价格下降),但这种方法取决于需求增长率较低
• 减少交互,减少批量工作
• 只完成ruby中的部分工作 - 例如现有的传统后端+ rails前端,或者通过函数式编程系统进行事务+ rails前端

如果挑战者无法提出"规模"的具体含义,那么这不是一个有效的问题.

然而,如果挑战者确实想出了具体且可衡量的东西,那么我会使用一个时间盒式的尖峰解决方案(http://c2.com/xp/SpikeSolution.html)来返回一些数字 - 可能还有一些选项如何做到这一点.