假设我有两个falcor-routes
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并返回相应的IDS。然后，路由器将将这些ID与特定路由一起使用以填充实际值。不用Akward缓存对userService-implutions（需要在任何类似情况下都需要重复，例如地址，成本类型等），这将至少产生两个针对我的持久性后端的查询，这是一种更传统的方法，使用一种更传统的方法宁静的端点
GET /users/?offset=0&limit=10
很可能对一个单个都满足。
是否有一般最佳实践方法如何在这种情况下优化数据库查询，例如路由器和后端服务之间的一些巧妙的缓存？在模型的users路线中返回完整信息是不行的
不会同时拥有通用用户的路由，而用户名和划分路由则允许您使用单个DB请求处理get('users[0..10]["name","email"]')查询？
，例如
route: 'users[{ranges}]'
和
route: 'users[{ranges}]["name", "email"]'
第二个途径，因为它更具体，它将返回您只需一个DB请求的get('users[0..10]["name","email"]')查询所需的所有内容，而在任何其他字段上的用户查询（超过名称和电子邮件）将落到第一个路线。
jafar hussain引用文档：
来回答这个问题：路由器在服务层或REST API 上合适。在这些类型的API上使用路由器提供了足够的灵活性，可以避免客户往返，而无需引入重量级抽象。面向服务的体系结构在设计用于可扩展性的系统中很常见。这些系统通常将数据存储在不同的数据源中，并通过各种不同的服务将它们曝光。例如，Netflix在其微服务体系结构前使用路由器。
使用路由器直接访问单个SQL数据库很少是理想的选择。使用单个SQL商店的应用程序通常会尝试为每个服务器请求构建单个SQL查询。路由器的工作通过将JSON Graph文档不同部分的请求分开为单独的处理程序，并将单个请求发送到服务以检索请求的数据。结果，路由器很少有足够的上下文来产生一个优化的SQL查询。我们目前正在探索以后在Falcor中支持此类数据访问模式的不同选项。
我现在正在探索自己的是使用路由器来收集部分数据库查询，然后爬行JSON图结果合并这些部分查询，将它们作为一个对数据库执行，然后再次爬行图表以将值放置在位于正确的路径。使用ArangodB和AQL的LET语句绝对有可能有点棘手。我不知道SQL。
如果您正在寻找更简单的解决方案，则可以缓存索引到ID映射以尝试最大程度地减少数据库访问。詹姆斯·康克林（James Conkling）的答案也很好。