怎么讓前端程序員沒有后端也能完成項目

這篇文章主要講解了“怎么讓前端程序員沒有后端也能完成項目”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“怎么讓前端程序員沒有后端也能完成項目”吧！

直接把 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 一樣

@Biz.profile('買家', 'read') @Biz.profile('店長', 'read', 'create', 'update', 'delete') @Biz.profile('管理員', 'read', 'create', 'update', 'delete') @Biz.authentic({ rowPolicy: 'public' }) @Biz.published export class RegionFreightTmpl extends Biz.ActiveRecord {     @Biz.lookup     public readonly freightTmpl: FreightTmpl;     // 計費模式：按件（目前只有按件）     public freightTmplType: string;     public firstPrice: number;     public firstAmount: number = 1;     public additionalPrice: number;     public additionalAmount: number = 1;     public regions?: string; }

查詢的時候直接用這個 class 來指代這張數據庫表就可以了。

視圖表

能夠做好權限校驗的前提是只暴露單表的簡單查詢。那么 count / sum / join 這些怎么處理? 難道是要發明一種 SQL 變種，然后搞 SQL 解析么?

一個簡單的做法就是引入“視圖表”的概念。把這些聚合查詢都建模成一張虛擬的視圖表。這樣在查詢的時候仍然是單表查詢。

• 解決了 rpc 請求的時候如何表達復雜 query 的問題，避免了 sql over http

• 解決了權限校驗難以確定目標是什么的問題

物化視圖表

如果所有的聚合查詢都要按需計算則會非常慢。經常我們需要一些按日期，按維度提前聚合好的中間結果。這個可以用物化視圖表來表達

@(Biz.view`SELECT id, gender, age, city, SUM(OrderItem.cost) AS total FROM ${impactSet} JOIN ${User} on User.id = impactSet.userId LEFT JOIN ${Order} on User.id = Order.userId LEFT JOIN ${OrderItem} on Order.id = OrderItem.orderId`) @(impactSet`SELECT DISTINCT(Order.userId) AS userId FROM ${ Order }`) @(impactSet`SELECT DISTINCT(Order.userId) AS userId FROM ${ OrderItem } JOIN ${ Order } on Order.id = OrderItem.orderId`) @Biz.source(Starriness, { dataSource: 'clickhouse' }) export class UserWithTotal extends Biz.SqlView {     public readonly id: string;     public readonly userId: string;     public readonly created_at: Date;     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

感謝各位的閱讀，以上就是“怎么讓前端程序員沒有后端也能完成項目”的內容了，經過本文的學習后，相信大家對怎么讓前端程序員沒有后端也能完成項目這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！