Node.js躬行記（8）——通用接口

一、GraphQL

　　最近服務端的同事分享了GraphQL，他分享的目的就是要把我們與他們的數據庫隔離，這么做我們也求之不得。

　　我們組目前維護着一個后台管理系統，會直接讀取數據庫中的表，如果能隔離的話，就不需要寫Model文件了。

　　后面再進一步了解后，明白了服務端推這個GraphQL的用意，其實就是讓我們自己去維護GraphQL服務，包括客戶端也去自己維護。

　　那這和我直接讀取數據庫做路由，區別不是很大了，無法解決當前我們的痛點，而且我在前端頁面中還需要制定數據結構，比之前還多了一步。

　　況且如果需要緩存的話，還不能直接調用GraphQL的接口。如果我們人員充沛的話，這么分一點問題都沒有，但是現在人員非常緊張。

　　我們還要花大精力做數據整合和處理，而前端常規的工作諸如性能優化、頁面交互、組件化、工程化等都沒時間深入研究。基於此，還得另辟蹊徑。

二、通用接口

　　由於后台管理系統大部分的操作都是增刪改查（數據庫基於MySQL，ORM基於Sequelize），所以可以抽象出一套這類的通用接口，從而就能避免在 Router 和 Service 兩層中新增不必要的文件。

• api/get：讀取一條數據（單表查詢）

• api/gets：讀取多條數據（單表查詢）

• api/head：讀取聚合數據，例如count()、sum()、max()和min()

• api/post：提交數據，用於增加記錄api/put：更新數據

　　這套接口的研發受到了 APIJSON 這套開源項目的啟發。

　　數據庫表都是單表查詢，不支持聯表，若要聯表則單獨創建接口。查詢條件的語法直接參照 Sequelize，沒有做單獨的語法編譯。

　　由於接口的參數是一個JSON格式的對象，因此全部采用 post 的請求方式（Content-Type: application/json）。

　　以 api/get 為例，基於KOA框架，在 Service 層的方法是：

  /**
   * 數據庫查詢一條記錄
   */
  async getOne(tableName, where={}) {
    return this.models[tableName].findOne({ 
      where,
      raw: true
    });
  }

　　在 Router 層的方法是：

  /**
   * 讀取一條記錄
   * { 
   *    TableName : { 查詢條件 }
   * }
   * TableName是Model文件的名稱，並非數據庫表名
   */
  router.post('/get',
  async (ctx) => {
    const { body } = ctx.request;
    const tableName = Object.keys(body)[0];   //表名
    const where = body[tableName];                    //查詢條件
    // 將表名和查詢條件傳遞給數據庫方法
    const data = await services.common.getOne(tableName, where);
    ctx.body = { code: 0, data };
  });

　　其中 TableName 是服務端中Model的文件名（並非數據庫中的表名），對象中的字段都是SQL的查詢條件。

　　粗略估算一下，如果將管理系統的接口替換成通用接口，那么可節省至少450個接口，占總接口的40%左右，並且 Service 中的方法也會大大減少。

　　已將通用接口的前端代碼整合到 shin-admin 中，后端代碼整合到 shin-server 中。