摘自“Beautiful Architecture”，第6章

随着用户渐渐了解这些数据交换的无缝性，使用这些平台API的开发者知道这些数据集是很独特的。开发者访问自己的数据的模式与访问Facebook数据的模式有着很大的不同。例如，Facebook的数据位于HTTP请求的另一端，通过许多HTTP连接来调用这些方法增加了开发者自己页面的延迟和开销。他自己的数据库也提供了更大粒度的访问，优于Facebook平台API中的几十个方法。使用他自己的数据和SQL这样熟悉的查询语言，他可以选择一个表的特定字段，对结果集排序或进行限制，匹配其他的指标，或进行嵌套查询。如果平台的API不能够让开发者在平台的服务器上进行智能的处理，开发者就必须经常获取相关数据的超集，收到数据后再在他自己的服务器上进行这些标准的逻辑转换。这可能成为严重的负担。

实际问题：从Facebook平台API获取数据要比获取内部数据的开销大很多。

随着应用越来越多地使用外部数据平台，诸如带宽占用、CPU负载和请求延迟等因素很快累积起来。难道我们没有在自己的单个应用栈的数据层中对此进行优化吗？没有技术让我们通过一次调用取得多个数据集吗？如果在这个数据层中进行选择、限制和排序，结果会怎样？

数据解决方案：类似内部数据采用的模式，实现外部数据访问模式：一种查询服务。

Facebook的解决方案称为FQL，我们将在6.3.2节中详细介绍。FQL很像SQL，但它将平台数据转换成字段和表，而不是简单松散地定义为XML schema中的对象。这让开发者能够在Facebook的数据上使用标准的数据查询语义，这种方式可能与他们取得自己数据的方式一样。同时，将计算推到平台一端的好处与将操作通过SQL推到数据层的好处是相似的。在这两种情况下，开发者有意识地避免了在应用逻辑中进行这种处理的代价。