GraphQL：现状分析

我们先看看 GraphQL 本质上做了什么事儿．先定义好一些指标和维度，然后让使用方在这个范围里，随意的组合使用。这么做行不行？当然行。

我们很多年前做开发的时候就考虑过，直接让前端开发人员，想要什么数据直接自己拿，可以不？可以．最简单的就是直接开放数据库的select 权限给前端，直接js 里写 SQL , ajax给后台执行完返回 json 不就得了吗．事实上，很多年前有 JS 库这么干的，微软20 年前也联合过几个公司搞个这种直接在线 httP 吐数据结构的技术.

这样做有什么坏处？前端需要的不一定是直接的按表结构来做的数据。因为表是为了存储方便的，而并不是跟业务和用户操作一一对应的．那么怎么把数据按业务需要的查询方式来聚合呢？这就是很多OLAp 框架和报表系统的模型干的事情了．我们先定义好查旬的数据范围和业务上的意义。比如说鼎鼎大名的 Cognos ，我们先拿到原始的数据源比如说是一个 DB 和里面的很多表 Table ，然后根据业务需要来定义指标和维度，做成我们需要对外提供的一个数据层 Cube ，然后基于这个 Cube 我就可以做各种查询操作二。开源的可以用 mondrian 之类的。

我们回过头来看看，跟 GraphQ 的定义 schema 定义哪些数据可用，其实本质上是一样的，这套思路， 20年来一直都有人在玩，而且玩的更深入。不同的是 GraphQL 比较轻薄＋使用 REST 下，但是 Cognos 和 mondrion 解决了 OLAp 什么问题呢？并不是使用方式的问题，而是大量的中间层的数据聚合和重用，这非常之关键。缓存有两种模式，一种是直接用内存或 Redis 之类的 cache ，缓存了所有的可用数据，包括原始数据和最终数据。但是如果有大量的复杂业务，那么我们是需要有很多中间层的数据缓存的，这些