回来接手的第一个和数据结合比较紧密的需求，做下总结，主要是数据访问的流程之前接触过也忘得差不多了，需要做下总结备忘。

首先做下数据流的描述，整个工作台的数据访问其实是建立在ElasticSearch上的，好处主要是搜索上很快，自己使用的过程中也确实感受到了，查询方面确实要比直接从MySQL查询快多了。因为在Laravel中数据源基本都直接以Model形式访问，所以基本的访问方式其实可以用基本的Model访问数据方式来实现。当然也有某些ES DSL的扩展库，可以实现ES的查询方式，之后有机会再做下记录。

从ES查询到数据后，会存在这样一种使用情景。在MySQL中反映出来就是一个页面展示多个数据表的数据，那么一般的操作是做表连接查询，当然连接查询会有性能问题，那么另外一种情况就是写一个拼接数据的函数分别访问多个数据表最后完成数据拼装。那么反映在ES中索引的数据又该怎么处理呢？脑测一下其实访问多个索引再拼装数据其实也不是不行。但实际项目中的数据量乃是千万到亿的数量级。性能问题是绝对会存在的。所以实际的使用中在查询完ES后又使用了GraphQL来实现数据拼接。

说起GraphQL，之前应该做过一点记录，但确实理解不深。其实从个人方面来解释，这个查询语言就是便利了数据的组织返回，相比RESTful API那种情况，每次请求一个复杂结构的数据，都得请求不同的API。GraphQL做的是把整个数据的结构都配置出来，根据后面请求包含的数据格式再组装数据返回。有点一劳永逸的感觉。反映在项目中就是对每一个索引建立一个GraphQL Type，对每个字段进行类型的描述，多个索引间的关系也可以通过对象类型来绑定。

内容大概就是这些。然后简述一下续作完成过程中涉及的文件。首先是一个配置文件，配置了访问的数据字段和生成字段的显示等内容，个人感觉实际上就是通过这里的配置生成graphQL请求的。然后页面显示的内容实际上应该是分成两个部分的。负责页面的controller实际上不负责返回数据，而负责的是页面组件的返回，和导出之类的配置。实际的数据返回是在TableApiController中完成的，具体细节暂时不详。数据的请求处理和数据组装是在Service文件中完成的。而布局等内容基本上和之前做i过的一致，主要是拆分了不少数据展示方面的模板，需要仇视假案学习一下布局拆分的逻辑。

大概内容就是这些。比较难的地方主要是数据流那一部分，因为涉及到很多Type的修改，最终走到数据展示的点的过程中试错了很多次，比较艰难，其他内容倒是还好。再就是在完成需求的过程中加了不少重复的页面，最后修改的过程中直接工作量翻倍，后面只好修改成增加参数做区分即可，下次注意一下就好了。