关于前端:前端与数仓可以实现无壁沟通吗

豆皮范儿的小伙伴们大家好，明天咱们带来了与常常与数据打交道的数据仓库，作为技术不舍边界的字节同学，咱们前端同学也会去了解和深刻业务，能够很好的了解整个数据链路，能力更好的做好每一个数据产品。

本文作者：小隐同学

大数据时代对前端的赋能绝非仅为“从后端接口获取数据，而后以肯定形式展现在页面中”而已，前端从事人员被给予越来越高的期待。尤其是当你正在一个数据平台类的公司或部门乘风破浪，那么对整个数据链的理解，甚至一个人 cover 整个链条，都可能成为常态。

如果你被问到：“前端与数仓如何实现交互”？你将如何给出答案？

如果是之前的我，我会说，前端是与后端间接交互的，而与数仓间接交互。

评审 -> 需要剖析 -> 前后端约定接口文档 -> 开发 -> 前后端联调 & bugfix -> 测试回归 -> 上线

在下面的流程中，前端最重要的工作就是将后端传来的数据“妥善安置”，长此以往，便成了无聊的“数据搬运工”。当然，这样的想法，很容易让我产生对前端意义和乐趣性的狐疑。

而前端与数仓，仿佛是隔了后端这一层“壁”的。像数仓做了什么工作，以后需要波及的口径都有哪些，别离是什么含意，原始数据库表中都存了什么，没有留神过。数仓对于前端，好像是一片“灰色地带”，至于前端与数仓间接沟通？从未尝试，从未思考过。

在数据平台部门，每个人必不可少的就是与海量的数据打交道。

作为入职不久的新人，我逐步意识到，前端不能甚至不容许仅仅关注后端传过来哪些字段，此外还须要花肯定的工夫，去关注整个“数据链条”。从数据底表存的是什么，字段含意，表之间如何通过抽取、拼接、计算生成了最终取数的一张“大宽表”，经验了怎么的例行工作，前端最好都要理解一下。

为什么？

因为在理解了这些数据的含意之后，能力开发过程中施展火眼金睛、高深莫测的能力，把呈现的不合理数据，及时地反馈给后端、数仓。以前端角色发力去推动我的项目的过程，这也正是一种 owner 意识的体现。这样无意识的锤炼，对于前端来说，不仅能增加数仓方面的能力，甚至能够减少一部分的数据分析师的根本素养。

xx 我的项目开发的启动，因为后端人力不足而一再推延，成为咱们进行跳过后端服务器的前端数仓的“去壁化”计划摸索的一个契机。

首先，咱们钻研了以后部门成型的开发模式。借助部门已有的几款优良的数据产品，数仓同学和后端同学能够别离在不同的平台上进行 SQL 语句验证、数据同步、接口取数等基本操作。前端参加的环节仅有对接口和向后端服务申请数据。

当没有后端服务时，前端如何与数据间接产生交互？

此时首先想到的是，node 赋予前端的更大可能性。家喻户晓，node 的呈现，让前端开发既 Ajax 之后，有了全新的风貌，在开发效率，性能等层面都有质的晋升。

应用 node 作为服务端，即 BFF（Backend for Frontend）层，是为前端服务的后端，是各种端（Browser、APP、miniprogram）和后端各种微服务、API 之间的一层“粘合剂”。BFF 层次要的业务场景大多数是申请转发、数据组织、接口适配、权鉴和 SSR 等聚合型的业务场景。

如果将后端服务替换成用 node 开发和保护的 BFF 层，则基于原有的开发模式，将呈现下图所示的一种新的开发模式。

在新模式的流程当中，数仓同学写 SQL 并在 DataWind 平台查问验证通过之后，则能够将数据集导入数据服务平台，依据 sql 和具体参数等生成相应 API。此时工具或者微服务等工具化 / 自动化的辅助工具，可获取基于数据服务平台对应的 SQL 和返回的数据后果，同时基于查问的数据后果解析成对应的 Schema 中。生成的 shcema 会导入到 BFF 层服务中，前端可依据 schema 晓得有哪些数据，数据格式的构造等信息。

同时，对于一些较为轻量的数据库操作，BFF 层能够借助 ORM 框架，间接进行 Mysql 库上的 CRUD。如果我的项目前期开始接入较为简单的数据库操作，或者数据获取的纬度多元且非常复杂，则可接入后端，对 BFF 层裸露接口。

因而，新模式具备以下显著劣势

1. 前端人员上手 node 较快，前后端工作仅由前端同学负责，能够无效升高人力老本。

2. 前端因为间接和 Node 层服务进行交互通信，同时可通过无效进步开发人员的开发效率，有更多的可能性。

3. 采纳工具化 / 自动化的形式，能够无效升高因简单类型的数据而产生的前后端沟通协同老本，明显提高开发效率。

4. 可随时接入后端服务，Node 层可施展更多功能。具备较高可扩展性。实在后端接入后，可更加聚焦于模块化性能开发，而非聚焦于 UI 性能开发。

5. 利用 DataRocks 平台查问数据的能力，通过工具 / 平台与 Node 中间层服务买通，升高后端同学的数据搬运老本及前后端对接数据的合作老本。

后面提到，不论是 BFF 端，还是实在的后端，咱们心愿服务端能够面向模块开发而不是面向 UI 开发，即依据不同页面所须要的数据进行不同接口的开发。服务端能够一次性定义完所有性能，而不须要一一开发。

服务端理论返回的数据，由前端来指定的，即“Ask for exactly what you want”。这是一种进步开发效率，节俭沟通老本的形式。另外对于前端工程师来说，能够在 BFF 层应用一种更容易上手的查问数据的 API 计划，从而升高学习老本。

因而在 API 设计上，咱们抉择了 GraphQL：一种用于 API 的查询语言。

所谓“Ask for exactly what you want”，总共分几步？

首先，强类型的 schema。指定了接口返回字段的类型以及数据结构；

type Project {
  name: String;
  tagline: String;
  developers: [User];
}
type User {
  id: Int
  name: String
}

其次，query 示意你要申请的数据，比方此时你只关注 tagline 和开发者的名字；

{project(name: "IM-GameBI") {
          tagline,
    developers {name}
  }
}

最初，失去可预测的后果。后果依照你想要的数据及构造返回。

{ "project": {
    "tagline": "A game intermodal project"
    "developers": [{"name": "wangning.front"},
       {"name": "wuhongjiang"},
       {"name": "zhangkun.fe"},
    ]
  }
}

劣势 1：GraphQL API 基于类型和字段的形式进行组织，而非入口端点。你能够通过一个繁多入口端点失去你所有的数据能力。因为强类型的 Schema，GraphQL 保障利用只申请可能的数据，还提供了清晰的辅助性错误信息。利用能够应用类型，而防止编写手动解析代码。

劣势 2：相比于典型的 REST API 申请多个资源时得载入多个 URL，GraphQL 能够通过一次申请就获取你利用所需的所有数据。这样一来，即便是比较慢的挪动网络连接下，应用 GraphQL 的利用也能体现得足够迅速。

劣势 3：使 BFF 层保护代码的老本较低。GraphQL API 字段和类型的新增和废除，不影响现有的查问，能够更好保护的服务端代码。

新模式引入 GraphQL 后的角色及多端交互的细节如下图。

GraphQL 在 API 不须要频繁变动版本时将施展其最大的劣势。一旦 API 版本频繁变动（如我的项目启动后期），则须要开发者手动保护大量的 Schema 的变更。

在理论开发中，咱们发现，如果 Datarocks 中的某个 API 返回的内容发生变化，则 Schema 须要及时失去更新（字段的增删改、数据结构的变动），同时申请数据的 query 也要随之变动。这是“牵一发而动全身”的成果。重复批改 Datarocks API、Schema、query 以及前端的各种 type 限度，实际上拉低了开发的效率。

因而自动化计划必须提上日程。自动化的指标大略如下图所示。

@dp/open-api-auto-tools：基于 Datarocks 的接口动静生成 OpenAPI 文件（oas.json）的 Cli 工具。开发者调用命令时，须要通过 sso 鉴权。
openapi-to-graphql：将 DataRocks 的 OpenAPI 标准转化为 GraphQL Schema。
@dp/byted-gulu-graphql：集成 openapi-to-graphql，实现鉴权、主动生成 Schema（可含自定义 Schema），并将其挂载到 app 实例上。
@dp/graphql-codegen-util-plugin：集成了 graphql-code-generator 实现将 query 转化成对应的各模块 query，以及接口类型、参数类型。

构建自动化工具库，实现主动地生成用于类型查看地 ts 文件、GraphQL Schema 等，解放双手，晋升开发效率。通过自动化后，BFF 端代码简直无手动输出代码，若 Datarocks OpenAPI 产生扭转，BFF 只须要 run 一遍脚本从新生成 oas 文件即可；前端无需手动保护类型文件，仅需依照后端接口调用模版申请数据即可。

![](https://tech-proxy.bytedance….）

目前咱们所围绕着是通过 BFF 层，作为承接数据端和前端的桥梁，而最终咱们想要打造的是，通过一直演进和丰盛的数据服务 BFF 层，与数据组件市场两者联合起来，可能进一步地将数据的能力进行泛化和下沉，使数据平台所生成的中台数据能力可能更疾速、更便捷的被第三方平台应用和接入。
咱们也在踊跃的在这一方面进行摸索，置信将来不仅可能提供“数据服务”，更能够通过“数据组件集市”的形式为大家提供另外一个维度的服务。

以上就是前端与数仓“去壁化”沟通的一次实际，也是 GraphQL 落地在实在我的项目中的一次尝试。曾经验证了计划的可行性，并且在理论我的项目中胜利落地。

现阶段 GraphQL 还属于陈腐事物，很多技术细节依然值得摸索和验证。比方它的复杂性较高，它用用来衡量比方缓存这样辣手的性能，因为 GraphQL 没有像 REST API 一样重用 HTTP 缓存语义。随着业务的扩大，咱们对此开发模式的摸索也将越来越深刻。

也欢送大家应用这一新模式开展摸索，一起探讨和学习。

Nate Barbettini – API Throwdown: RPC vs REST vs GraphQL

关于前端:前端与数仓可以实现无壁沟通吗

前言

一、在数据平台，一个前端要做好的心理转变

二、前端数仓的“去壁化”计划

1. BFF 层作为服务端

2. GraphQL：一种用于 API 的查询语言

三、“去壁化”计划的自动化摸索及落地

1. 工具链

2. BFF 层自动化流程

3. 前端自动化流程

四、瞻望

五、结语

参考

The End