使用falcor-router引用減少SQL查詢的數量

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。 然后路由器將這些ID與特定路由一起使用以填充實際值。 如果沒有對UserService實現進行緩慢的緩存（對於任何類似的情況需要重復，例如地址，成本類型等），這將對我的持久性后端產生至少兩個查詢，這是一種使用單一的更傳統的方法RESTful端點

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

很可能只滿足於一個。

是否有一般的最佳實踐方法如何在這種情況下優化數據庫查詢，例如通過路由器和后端服務之間的一些聰明的緩存？ 返回模型的users路線中已經存在的完整信息是不可取的，因為我們的用戶可能具有到用戶自己的朋友的圖表鏈接。

Answer 1

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

例如

route: 'users[{ranges}]'

和

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

第二個路由，因為它更具體，將返回get('users[0..10]["name","email"]')所需的一切get('users[0..10]["name","email"]')查詢只有一個數據庫請求，而用戶查詢任何其他字段（超出名稱和電子郵件）將落入第一條路線。

Answer 2

這個問題在這里由Jafar Hussain引用文檔回答：

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

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

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

如果您正在尋找更簡單的解決方案，則可以緩存index-to-id映射以嘗試最小化數據庫訪問。 James Conkling的回答也很好。