如何让前端程序员没有后端也能完成项目

开发 前端
直接把 Mysql 暴露在公网给前端使用会有什么问题?要做到 Backend as a "Database",就知道如何解决。

 [[356823]]

答:Backend as a Database, Sort Of

直接把 Mysql 暴露在公网给前端使用会有什么问题:

  • I/O 边界 => 性能考虑
    • 批量获取多条数据
    • 对数据进行 count / sum 等聚合
    • 把聚合结果做提前计算,冗余字段
  • 组织边界 => 安全考虑
    • 数据权限校验,防止非法访问
    • 校验业务规则
      • 产生的订单价格应该等于商品单价之和
      • 出库单要创建,需要xxx领导签字单

要做到 Backend as a "Database",就是回答以上问题如何解决。

User 表

Mysql / Postgresql 的权限太粗了。肯定是要在 Mysql / Postgresql 外边套一层去校验权限。这里有如下的挑战要解决

  • B 端权限需要非常细致,不仅仅要到行,甚至到格。权限可能是按职位授予,也可能是因为工单分配临时授予。
  • 权限校验开销不能太大,如果拿来做 C 端业务,单据数量和用户数量都可能会非常大。要减少因为行级别权限引入的开销。所以要能按需打开不同的授权模式。
  • 没有登录的用户需要登录,或者能够匿名浏览。如何方便给没有用户的访问做适当的提权。
  • 非真实人类用户的访问,比如夜间的批处理,需要能够有机器人的账号
  • 账号的初始化是如何描述的,谁来分配最初的那个管理员
  • 如果有多个 Project,每个 Project 有自己的用户体系,不同的 User 表。这两个 Project 要互相访问,用什么 User 身份?

解决了以上问题,我们就获得了一个内建权限的“Database”,可以开放到公网给前端访问。实际拉数据的时候,用的是人类用户自己的身份。只要用户自己对要访问的数据表或者行有权限,就可以访问到,否则就访问不到。

业务数据表

写一个 Typescript 的类,然后把 Mysql 的表建好。和 Java Hibernate 一样

  1. @Biz.profile('买家''read'
  2. @Biz.profile('店长''read''create''update''delete'
  3. @Biz.profile('管理员''read''create''update''delete'
  4. @Biz.authentic({ rowPolicy: 'public' }) 
  5. @Biz.published 
  6. export class RegionFreightTmpl extends Biz.ActiveRecord { 
  7.     @Biz.lookup 
  8.     public readonly freightTmpl: FreightTmpl; 
  9.     // 计费模式:按件(目前只有按件) 
  10.     public freightTmplType: string; 
  11.     public firstPrice: number; 
  12.     public firstAmount: number = 1
  13.     public additionalPrice: number; 
  14.     public additionalAmount: number = 1
  15.     public regions?: string; 

查询的时候直接用这个 class 来指代这张数据库表就可以了。

视图表

能够做好权限校验的前提是只暴露单表的简单查询。那么 count / sum / join 这些怎么处理? 难道是要发明一种 SQL 变种,然后搞 SQL 解析么?

一个简单的做法就是引入“视图表”的概念。把这些聚合查询都建模成一张虚拟的视图表。这样在查询的时候仍然是单表查询。

  • 解决了 rpc 请求的时候如何表达复杂 query 的问题,避免了 sql over http
  • 解决了权限校验难以确定目标是什么的问题

物化视图表

如果所有的聚合查询都要按需计算则会非常慢。经常我们需要一些按日期,按维度提前聚合好的中间结果。这个可以用物化视图表来表达

  1. @(Biz.view`SELECT id, gender, age, city, SUM(OrderItem.cost) AS total 
  2. FROM ${impactSet} 
  3. JOIN ${User} on User.id = impactSet.userId 
  4. LEFT JOIN ${Order} on User.id = Order.userId 
  5. LEFT JOIN ${OrderItem} on Order.id = OrderItem.orderId`) 
  6. @(impactSet`SELECT DISTINCT(Order.userId) AS userId FROM ${ Order }`) 
  7. @(impactSet`SELECT DISTINCT(Order.userId) AS userId FROM ${ OrderItem } JOIN ${ Order } on Order.id = OrderItem.orderId`) 
  8. @Biz.source(Starriness, { dataSource: 'clickhouse' }) 
  9. export class UserWithTotal extends Biz.SqlView { 
  10.     public readonly id: string; 
  11.     public readonly userId: string; 
  12.     public readonly created_at: Date; 
  13.     public readonly total: number; 

物化视图的问题在于什么时候刷新。通过用 SQL 定义 impactSet,我们可以由 mysql binlog 触发物化在 clickhouse 中的物化视图表刷新。

用户行为表

物化视图的来源是业务数据。用户行为因为数据量比较大,不太适合直接插入到 mysql 中。把用户行为单独提供一张宽表来记录用户做过什么操作。写入可以是内存缓冲,或者经过 kafka 这样的队列缓冲。

宽表的列应该是按业务需求扩展的,如果业务上关心用户操作的订单id,或者商品id,则要加上这些字段。大概的 api 也类似 mixpanel 这些老牌分析厂商的上报接口。

物化视图在计算报表的时候可以 join 用户行为表和业务数据表来得出分析结果。

批量查询

一次 rpc roundtrip 只能发一条查询太慢了。那支持一个数组,一次可以提交多条查询就好了。至于前端代码中怎么把多个组件的查询聚合到一个 rpc 中,这个就看前端的 data query 框架是怎么来弄了。无非就是全局搞个 buffer,在“合适的时候”刷一下这个 buffer,批量查一次。

存储过程

细粒度的用户权限只能解决数据完全被一个用户拥有的问题。很多时候数据是协作数据,有多个 stakeholder,那么就必须经过协商好的规则去修改数据,而不是一个用户说了算。例如你可以决定今天的日记本里随便写啥,但是不能决定把今天晚饭的订单改成0。日记是你拥有的,但是订单是多个相关方都关心的。

解决业务规则校验后写入的问题就是存储过程了。前端同学肯定是希望用 javascript 来写存储过程。实际上就是所谓 FaaS 的云函数。本质上就是后端代码仍然有,只是换了一拨人来写。

如果业务规则比较简单,例如只是一个状态机的转换图,则可以用配置替代code。当然大部分时候,复杂的业务逻辑,上 javascript 是最直观的。

Data Migration

数据库表结构变更了肯定还是要写 SQL 来升级数据库的,标准做法没啥说的。

Backend as a Database

  • 用 RPC 接口提供了一个类似 Database 的东西
  • 把后端业务切分成了 User表/业务数据表/视图表/物化视图表/用户行为表/存储过程/DataMigration 等预设的概念,变得更规整
  • 除了“需要经过业务规则校验之后写入”这个例外,其他的后端接口都不需要上通用编程语言,可以用配置或者SQL定义解决
  • 这个解法既不是 GraphQL,也不是经典的 BFF

 

责任编辑:张燕妮 来源: 知乎
相关推荐

2021-08-28 23:26:14

程序员编码电脑

2020-06-05 07:52:25

程序员离职编码

2015-12-15 09:37:18

程序员设计勤奋

2020-02-14 15:16:16

程序员表白浪漫

2017-12-15 15:09:42

2013-05-27 17:12:41

面试Google

2010-07-29 11:00:59

程序员

2020-09-14 11:00:37

程序员技术日志

2011-04-28 09:26:06

程序员

2012-09-11 10:33:40

2015-12-09 09:17:11

情绪厌倦程序员

2015-12-07 11:44:31

程序员厌倦工作

2018-11-01 15:20:17

前端程序员编程语言

2021-03-29 10:14:45

程序员技能开发

2011-09-06 09:02:06

程序员

2011-06-02 09:02:36

程序员

2019-11-23 23:21:44

程序员前端全栈

2010-12-14 10:04:07

程序员

2014-10-13 13:40:07

程序员

2022-05-19 09:53:05

机器学习人工智能算法
点赞
收藏

51CTO技术栈公众号