減少SQL查詢與falcor路由器引用

Question

假設數我有兩個falcor的路由

route: 'users[{ranges}]' 

和

route: 'UserById[{integers:ids}]["name","email"]' 

而users返回引用到UserById -route。如果我再火查詢

get('users[0..10]["name","email"]') 

針對這一點，路由器首先評估users[0..10]部分將執行在數據庫上SELECT id FROM users LIMIT 10並返回相應的標識。然後路由器將使用這些ID與特定路線一起填充實際值。如果沒有對UserService-implementation（對於任何類似的情況，例如地址，成本類型等需要重複）進行不必要的緩存，這將對我的持久性後端產生至少兩個查詢，而使用單一的更傳統的方法RESTful端點

GET /users/?offset=0&limit=10 

很可能會滿足一個。

是否有一個通用的最佳實踐方法如何在此場景中優化數據庫查詢通過路由器和後端服務之間的一些聰明的緩存？返回模型的users路徑中的完整信息是一種禁忌行爲，因爲我們的用戶可能有鏈接到朋友的圖表鏈接，這些朋友本身就是用戶。

Answer 1

不會同時擁有通用用戶索引路由和用戶名和電子郵件索引路由，您可以使用單個數據庫請求處理get('users[0..10]["name","email"]')查詢嗎？

E.g.

route: 'users[{ranges}]' 

和

route: 'users[{ranges}]["name", "email"]' 

第二條路線，因爲它是更具體的，將返回你需要的get('users[0..10]["name","email"]')查詢W /只有一個DB要求的一切，而用戶查詢任何附加字段（除姓名和電子郵件）將落入第一條路線。

Answer 2

這個問題是由賈法爾侯賽因引用的文檔回答here：

路由器適合作爲通過服務層或REST API的抽象。在這些類型的API上使用路由器提供了足夠的靈活性，以避免客戶往返而不引入重量級抽象。面向服務的體系結構在設計用於可伸縮性的系統中很常見。這些系統通常將數據存儲在不同的數據源中，並通過各種不同的服務公開它們。例如，Netflix在微服務架構之前使用路由器。

使用路由器直接訪問單個SQL數據庫很不理想。使用單個SQL存儲的應用程序通常會嘗試爲每個服務器請求構建一個SQL查詢。路由器的工作是將對JSON Graph文檔不同部分的請求拆分成不同的處理程序，並將各個請求發送到服務以檢索請求的數據。因此，路由器很少有足夠的上下文來產生一個優化的SQL查詢。我們目前正在探索在Falcor未來支持這種類型的數據訪問模式的不同選項。

我正在探索自己現在正在使用路由器收集部分數據庫查詢，然後抓取JSON圖形結果合併這些部分查詢，執行他們作爲一個對數據庫，然後爬圖形再次將值放在正確的路徑上。儘管它有點棘手，但使用ArangoDB和AQL的LET語句是絕對有可能的。我不知道SQL。

如果您正在尋找更簡單的解決方案，您可以緩存索引到ID映射以嘗試並儘量減少數據庫訪問。 James Conkling的答案也很好。