作者 | Noah Gibbs

譯者 | 彎月，責編 | 屠敏

頭圖 | 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和域名。我特別懶，所以即使不用資料庫我也會使用Rails。所以我甚至不知道能不能在沒有資料庫的情況下運行Rails。

說實話，即使是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 翻譯，轉載請註明來源出處。