斗皮范儿朋友们，今天给大家带来了一个经常和数据打交道的数据仓库。作为不愿放弃技术的字节同学，我们前端同学也会对业务有所了解和深化。只有了解好整个数据链路，才能更好的做好每一个数据产品。本文作者：小印同学前言大数据时代前端的赋能绝不只是“从后台接口获取数据，然后以一定的方式展示在页面上”。前端人员被给予越来越高的期望。尤其是当你在数据平台公司或部门乘风破浪时，那么了解整个数据链，甚至一个人覆盖整个链条，可能会成为常态。1.在数据平台上，一个前端需要经历一个心理转变。如果你被问到：“前端如何与数据仓库交互”？你会如何回答？如果是以前的我，我会说前端直接和后端交互，间接和数仓交互。Review->需求分析->前后端协议接口文档->开发->前后端联调&bugfix->测试回归->上线以上流程中，最重要的工作前端的工作就是把后端传来的数据“妥善安置”，久而久之，就成了无聊的“数据搬运工”。当然，这样的想法很容易让我怀疑前端的意义和乐趣。前端和数据仓库仿佛被后端的“墙”隔开。比如数据仓库做了什么工作，当前需求涉及的口径是什么，每一个的含义是什么，原来的数据库表里面存的是什么，我都没有关注过。数据仓库似乎是前端的“灰色地带”。至于前端和数据仓库的直接通信？从未尝试过，也从未想过。在数据平台部门，处理海量数据对每个人来说都是必不可少的。作为一个刚进公司的新人，逐渐意识到前端不能甚至不允许只关注从后端传过来哪些字段。此外，关注整个“数据链”也需要一定的时间。从数据底层表存储的是什么，字段的含义，表是如何抽取、拼接、计算生成一张“大宽表”供最终接入，经历了哪些常规任务，最好让前端看懂一遍。为什么？因为只有了解了这些数据的含义，才能利用开发过程中眼尖、眼明手快的能力，将出现的不合理数据及时反馈给后端和数据仓库。利用前端的作用来推动项目的进展，也是业主意识的体现。这样有意识的锻炼，对于前端来说，不仅可以增加数据仓库的能力，甚至可以增加一些数据分析师的基本素质。二、前端数据仓库的“脱墙”计划1、BFF层是服务端xx项目开发的起点。由于后端人手不足，一再延期，也成为我们跳过后端服务器对前端数仓“拆墙”的一次程序探索的机会。首先我们考察部门目前形成的发展模式，借助部门已有的几款优秀的数据产品，数据仓库同学和后端同学可以进行SQL语句校验、数据同步、以及不同平台的接口访问，前端参与的环节只有接口和向后端服务请求数据，没有后端服务时，前端如何直接与数据交互？这时候要想到的是node给前端更大的可能性，众所周知，node的出现让前端开发继Ajax之后焕然一新，对前端开发有了质的提升开发效率和性能。以node为服务端，即BFF（BackendforFrontend）层，是为前端服务的后端，是各个端（Browser、APP、小程序）与各个后端微服务和API之间的一层“胶水”。BFF层的主要业务场景大部分是请求转发、数据组织、接口适配、鉴权、SSR等聚合业务场景。如果后端服务换成node开发维护的BFF层，在原有开发模式的基础上，会出现如下图所示的新开发模式，在新模式的过程中，数据仓库同学在DataWind平台上编写SQL并通过查询验证后，就可以导入数据了设置到数据服务平台，根据SQL和具体参数生成相应的API，此时工具或微服务等工具化/自动化辅助工具可以基于数据服务平台获取相应的SQL和返回的数据结果，以及同时将查询出来的数据结果解析成对应的Schema，生成的shcema会导入到BFF层服务中，前端可以根据schema知道有什么数据，数据格式的结构等信息。同时对于一些相对轻量级的数据库操作，BFF层可以借助ORM框架直接对Mysql库进行增删改查。如果项目后期开始接入比较复杂的数据库操作，或者数据采集的纬度多样，非常复杂，可以接入后端，将接口暴露给BFF层。因此，新模式具有以下明显优势：1、前端人员上手node速度更快，前后端工作仅由前端同学完成，可有效降低人力成本。2.前端直接与Node层服务交互，具有更多的可能性，可以有效提高开发者的开发效率。3、工具化/自动化的方式，可以有效降低复杂数据类型带来的前后端沟通协作成本，显着提升开发效率。4、后台服务随时接入，Node层发挥更多功能。它具有很高的可扩展性。接入真实后台后，可以更专注于模块化功能开发，而不是UI功能开发。5.利用DataRocks平台查询数据的能力，通过工具/平台打通Node的中间层服务，降低后端同学的数据处理成本和前后端的协作成本-结束对接数据。2.GraphQL：一种API的查询语言前面提到，无论是BFF端还是真正的后端，我们都希望服务端能够面向模块开发而不是UI开发，即根据需要的数据不同的页面。开发不同的接口。服务端可以一次性定义所有功能，无需一个一个开发。服务器实际返回的数据是由前端指定的，即“Askforexactlywhatyouwant”。这是一种提高开发效率，节省沟通成本的方式。此外，对于前端工程师来说，可以在BFF层使用更易用的查询数据的API方案，从而降低学习成本。所以对于API设计，我们选择了GraphQL：一种API查询语言。所谓“问心无愧”，一共有多少步呢？首先，强类型模式。指定接口返回字段的类型和数据结构；输入项目{名称：字符串；标语：字符串；developers:[User];}typeUser{id:Intname:String}其次，query表示你要请求的数据，比如所以此时你只关注tagline和开发者的名字；{project(name:"IM-GameBI"){tagline,developers{name}}}最后，您将获得可预测的结果。结果根据你想要的数据和结构返回。{"project":{"tagline":"游戏联运项目""developers":[{"name":"wangning.front"},{"name":"wuhongjiang"},{"name":"zhangkun.fe"},]}}优点1：GraphQLAPI是根据类型和字段组织的，而不是入口端点。您可以通过单个入口点获得所有数据功能。由于强类型模式，GraphQL确保应用程序只请求可能的数据，并且还提供清晰且有用的错误消息。应用程序可以在不编写手动解析代码的情况下使用类型。优势二：与典型的RESTAPI请求多个资源时加载多个URL相比，GraphQL可以一次请求获取应用程序所需的所有数据。这样，即使在移动网络连接速度较慢的情况下，使用GraphQL的应用程序也可以足够快地执行。优点3：使BFF层维护代码的成本更低。GraphQLAPI字段和类型的添加和弃用不会影响现有查询，并且可以更好地维护服务器端代码。新模式引入GraphQL后的角色和多端交互细节如下图所示。3、“去墙”方案的自动化探索与实现GraphQL将在API不需要频繁版本变更的情况下发挥最大优势。一旦API版本频繁变更（比如项目上线初期），开发者需要手动维护大量的Schema变更。在实际开发中，我们发现如果Datarocks中某个API返回的内容发生变化，schema需要及时更新（字段增删改查，数据结构变化），query请求数据也需要随之变化。这就是“一毛动全身”的效果。前端反复修改DatarocksAPI、Schema、query、各种类型限制，实际上降低了开发效率。因此，自动化方案必须提上日程。自动化的目标大致如下图所示。1.Toolchain@dp/open-api-auto-tools：基于Datarocks接口动态生成OpenAPI文件（oas.json）的Cli工具。开发者调用命令时，需要通过sso认证。openapi-to-graphql：将DataRocks的OpenAPI规范转换为GraphQLSchema。@dp/byted-gulu-graphql：集成openapi-to-graphql，实现鉴权，自动生成Schema（包括自定义Schema），并挂载到app实例上。@dp/graphql-codegen-util-plugin：集成graphql-code-generator，将查询转化为对应的模块查询，以及接口类型和参数类型。构建自动化工具库，自动生成类型检查、GraphQLSchema等ts文件，解放双手，提高开发效率。自动化之后，BFF端几乎不需要手动输入代码。如果DatarocksOpenAPI发生变化，BFF只需要运行一次脚本即可重新生成oas文件；能。2、BFF层自动化流程！[](https://tech-proxy.bytedance....)3、前端自动化流程！[](https://tech-proxy.bytedance....)4.展望目前，我们关注的重点是利用BFF层作为桥梁，承接数据端和前端。最终，我们要构建的是将不断演进和丰富的数据服务BFF层与数据组件市场相结合，进一步发展，以泛化和下沉数据能力，让数据平台产生的数据能力得到利用第三方平台访问更加快捷方便。这方面我们也在积极探索，相信未来我们不仅可以提供“数据服务”，还可以通过“数据组件市场”为您提供另一个维度的服务。五、结语以上是前端与数据仓库通信“脱墙”的一次实践，也是在实际项目中实现GraphQL的一次尝试。该方案的可行性得到验证，并在实际项目中得到成功实施。现阶段，GraphQL还是一个新生事物，很多技术细节还是值得探索和验证的。例如，它的复杂度更高，用于权衡缓存等棘手的功能，因为GraphQL不像RESTAPI那样重用HTTP缓存语义。随着业务的扩大，我们对这种发展模式的探索也会越来越深入。也欢迎您使用这个新模型一起探索、讨论和学习。参考NateBarbettini-APIThrowdown:RPCvsRESTvsGraphQLTheEnd
