帶Rails/Sinatra的只讀網絡應用程序

Question

我正在研究Rails中的管理Web應用程序。由於各種實際情況並不相關，支持此應用程序的數據庫將擁有支持另一個單獨網站所需的全部內容。看起來好像有兩個明顯的選項：

1. 構建一個web應用程序，以某種方式以只讀方式從同一數據庫中讀取數據。
2. 將RESTful API添加到原始應用程序，並以從API獲取其內容的方式構建第二個站點。

我的問題是這樣的：這些選項是否可行？如果是這樣，他們中的哪一個似乎是更好的選擇？ Rails，Sinatra或任何其他基於Rack的Web框架是否特別適合這類項目？ （我傾向於Sinatra，因爲它看起來比Rails更輕量，我認爲我的Rails體驗會很好地支持它。）

Thanks！

Answer 1

這兩個都是可行的，我已經在過去使用過，但我會採用API方法。

快速免責聲明：有一點不清楚的是這些應用程序在功能上有多不同。例如，我可以想象舊版本是一款適用於個人記錄的CRUD應用程序，而新版本則是一個報告應用程序，可以處理大型複雜的聚合查詢。這使共享數據庫（可能）更具吸引力，因爲訪問數據的方式重疊非常小。我假設下面這個不是的情況。

無論如何，API方法。首先，不好：

• 另一個依賴項（舊應用程序）。當它中斷時，它會關閉這兩個應用程序。
• 又一次獲取數據的跳躍，所以延遲時間更長。
• 使用現有代碼不如編寫新代碼更有趣。就是。

但在另一方面，把好：

• 更彈性的架構更改。您的「舊」應用程序的API可以進行測試，並且可以將數據庫放在心臟的內容中（在舊應用程序的上下文中），並將API保持其規格。您的新應用程序不會知道其中的差異，這很好。抽象FTW。這是「多一個依賴」硬幣的另一面。

• 同樣的觀點，但從不同角度來看：在我們共享數據庫的方法中，您的模式+所有SQL都是您的API，它有兩個客戶端，舊應用程序和新的。除非你的兩個應用程序使用相同的數據做了非常不同的事情，否則這絕不是最好的API。它的定義太差。

• 數據庫管理員/檢測儀器更好。比方說，你搞砸了一些查詢和軟管你的數據庫。它是哪個應用程序？這些查詢來自哪裏？基本上，與你的數據庫交互的東西越少越好。相關：在一個地方優化您的閱讀查詢，而不是兩個。

• 如果您在現有應用程序中對非API操作使用了RESTful路線，我猜你的API需求將與您現有的控制器代碼有巨大的重疊。這可能只是將您的數據轉換爲JSON，而不是將它傳遞給視圖。 Rails使用動作來響應API和用戶驅動的請求非常容易。所以如果適用的話，這是一個很大的勝利。

• 如果你發現你會發生什麼做希望在你的新應用程序中有一些可寫性？或者至少訪問某個領域的舊應用程序不關心（也許你已經添加了一個腳本）？在共享數據庫方法中，這只是毛病。另一方面，這只是擴展API的一個問題。

基本上，我唯一會選擇共享數據庫方式的方式是我討厭舊代碼並希望重新開始。這是可以理解的（我完全是這樣做的），但它並不是體系結構最健康的選項。

要考慮的第三個選項是在兩個應用程序之間共享代碼。例如，您可以創建模型代碼。現在你的API真的是一些知道如何與你的數據庫交流的Ruby類。更進一步，您可以編寫一個Sinatra應用程序並將其安裝在現有的Rails應用程序中，並重復使用它的大部分。然後，只需制定路由，以使它們看起來像獨立的應用程序到外部世界。這是否切實可行顯然取決於你的具體情況。

就特定技術而言，Sinatra和Rails都是不錯的選擇。我傾向於更大項目的Rails和更小的項目的Sinatra，但這只是我。做什麼感覺很好。