確切來說，Parse 第一代 API 使用 Ruby on Rails，後來經由內部團隊討論後，決定將 Ruby on Rails 轉向 Go 重寫。

“Was the rewrite worth it? Hell yes it was.”

“這麼做值得嗎？Parse 表示，天殺得太值得了。”

“Our reliability improved by an order of magnitude. More importantly, our API is not getting more and more fragile as we spin up more databases and backing services. Our codebase got cleaned up and we got rid of a ton of magical gems and implicit assumptions. Co-tenancy issues improved for customers across the board. Our ops team stopped getting massively burned out from getting paged and trying to track down and manually remediate Ruby API outages multiple times a week.”

“服務可靠性獲得了數量級的成長。更重要的是，我們的 API 不再變得愈來愈差，以致於需要更多資料庫及後端伺服器來支撐。我們的程式碼也變得更乾淨，擺脫了一大堆「神奇」的 Gems 及程式的隱含假設。而且也改善了我們與客戶的關係。我們的團隊再也不用耗費大量時間與精力，追查並手動修復 Ruby API 的異常，況且這種異常一個星期發生很多次。”

“As if that weren’t enough, the time it takes to run our full integration test suite dropped from 25 minutes to 2 minutes, and the time to do a full API server deploy with rolling restarts dropped from 30 minutes to 3 minutes. The go API server restarts gracefully so no load balancer juggling and prewarming is necessary.”

“而且還不只如此，我們的完整集成測試 (full integration test suite) 從 25 分鐘降至 2 分鐘，以及 API 服務從部署到重啟也從 30 分鐘降低 3 分鐘。API 服務的重啟可以非常優雅，不需依賴負載平衡器的調度調整，服務也不需要熱身。”

不過底下有人回應：

“one case dropped from 30 xlarge to 15 mediums…massive savings”

指出若不重寫，僅將 Ruby 改用 JRuby，有一個案例是將原本 30 台 xlarge 機器，降至 15 台 medium 機器。

我個人推估效能約提升 3 ~ 5 倍，以 Parse 的案例而言不如全面用 Go 改寫來得好，但改寫 Go 是大工程，若可以直接轉 JRuby 會輕鬆得多。

不過 JRuby 也不是想用就可以，底下有人繼續討論。

“Drop in you say? Does JRuby support native gems now?”

 

“It does not, but most popular native gems have JRuby versions.”

採用 JRuby 還是要依賴所使有的 Gems 是不是都支援 JRuby 才行。

最後，這篇文章引來了 Ruby 愛好者的回擊，認為 Parse 根本就是想攻擊 Ruby 程式語言。但也有網友聲援 Parse，認為 Parse 只是依據自己的需求做出選擇，並沒有刻意為了批評 Ruby / Rails 之意。