Side Project : node-graphql-api 後端資料服務

長期以來自己開發主要都著力都於前端
SPA的架構下，前後端是完全乾淨分離的開發模式
這架構下資料的來源 都仰賴API的服務提供

以前接案 後端的部分都是使用php寫API服務
之後技術發展移到nodejs上
剛好公司也因為沒有完整的API系統
自己也就跳下來使用nodejs建構一個基礎的架構方便使用
原本只是方便自己使用的架構
也衍生變成提供公司內多專案共通使用的API服務

在既有的包袱與人員的限制下
許多自己想要實作的部分 變的很難在現有專案上實作
因此才會以自己的side project
全新打造一個自己理想中的系統

project預期目標
1.提供可以多人共同開發的系統架構
  開發者只需關專於API的邏輯書寫，其他系統都會幫你搞定
2.標準Restful API資料服務
3.Graphql 資料服務
4.單元測試
   所有功能與api都透過單元測試確保穩定性與程式品質
5.封裝可執行檔
  可以執行檔做最簡單的部署到客戶端主機
6.提供通用資料查詢
  系統本身提供通用Restful API與 Graphql
  在安裝設定後，即可對資料庫table做CRUD處理

專案進行 持續維護中
node-api github位置
https://github.com/ozzysun/node-graphql-api

Graphql 巢狀結構查詢設計

要設計巢狀結構查詢
除了最上層會是建議query外 其他子結點都會是一個個的物件類型
query與物件的定義差別是
物件下並不會定義type而是有fields 來定義這個物件下包含的多個field定義
query下就會直接定義type 不會有fields的定義

多層次巢狀的物件結構 真正的資料操作可能只在某一層
但要注意的是 在巢狀結構下
上層的物件無論是否有作用 resolve一定要return
下層的物件才會被執行resolve
假設希望設計一隻通用的查詢功能
可以指定db主機,指定db,指定table做通用查詢的功能

1. table物件
fields即是完全對應到db table欄位

 tableObject {  
  name: table名稱,  
  fields: [  
   {  
    name: 欄位名稱１,  
    type: String|.. 對應欄位本身columnType  
   }..  
  ]  
 }  

2. db物件:
fields對應到db內所有的table
查詢取到的list 內容每一筆資料內容即是tableObj所定義的欄位
所以這裏的type會是tableObject 的list
這裏的resolve是真正執行db操作的地方

 DbObject {  
  name: db名稱  
  fields: [  
   {  
    name: tableName,  
    type: [tableObject]  
    resolve:() => {  
     真正執行的地方在這裡  
    }  
   }  
  ]  
 }  

3. host主機物件
fields內對應到主機內所有的db
每個field都是對應到一台db,所以類型會是dbType

 HostObject {  
  name: db名稱  
  fields: [  
   {  
    name: dbName,  
    type: DbObject,  
    resolve: async(parent, args, context, info) => {  
     // 這裡不需要做處理 但一定要回傳  
     return true  
    }  
   }  
  ]  
 }  

4.建立查詢
查詢即是這個程式的進入點type是主機物件
resolve沒有作用但必須要有return 才會往下解析

 mainQuery {  
  name: host,  
  type: HostObject,  
  resolve: () => {  
   return true  
  }  
 }  

graphql巢狀結構resolve處理

當schema有巢狀結構，需要在子元件上做resolve
例如 db/table/column 這樣的結構

ex:
db.js
{
  name: 'db',
  type: [table],
  resolve: async(parent, args, context, info) => {
    return 'xxxx'
  }
}
table.js
{
  name: 'table',
  type: [column],
  resolve: async(parent, args, context, info) => {
    // parent 是接收db resolve回傳的資料
    return 'yyyy'
  }
}
column.js
{
  name: 'column',
  type: String,
  resolve: async(parent, args, context, info) => {
    // parent 是接收table resolve回傳的資料
    // 真正執行程序
    return 'zzz'
  }
}

在每個type下都有自己的resolve做處理
巢狀結構會由最上層開始執行resolve
執行完的return內容會傳給子物件resolve內的parent接收
以上例子 真正的執行運算是在column上
即使上層物件不需要做任何resolve處理
也必須要有return值 否則子物件的resolve不會被觸發

以GraphqlSchema 建立Schema Object物件

在使用graphql 建立要使用的schema與resolve schema部分大多數都會以GraphQL schema language定義

// 使用GraphQL Schema Definition Language(SDL)定義schema
const typeDefs = gql`
  type Query {
    hello: String
  }
`;
// 建立resolve
const resolvers = {
  Query: {
    hello: () => 'Hello world!',
  },
};
// server運作使用
const server = new ApolloServer({ typeDefs, resolvers });

把定義好的typeDefs 與resolvers丟給server就可以跑了

但是如果建立schema的程序希望可以不要手寫SDL
可能是透過程序自動產生 就無法做到
ApolloServer 除了吃typeDefs, resolvers 參數外
直接產生好schema
透過
const server = new ApolloServer({ schema }); 執行
也是可以的

以下範例是說明完全利用Graphql.js來建立schma物件

const graphql = require('graphql')
const queryType = new GraphQLObjectType({
  name: 'Query', // 要建立的type名稱,整個graphql至少要有一個Query, 其他可以是自建類型名稱
  fields: {
    hello: { // 設定有一個hello的查詢
      type: graphql.GraphQLString, // 類型為基本scarla類型,可透過graphql取得
      args: { // 若這查詢可以提供輸入參數
        name: { //參數名稱
          type: graphql.GraphQLString, //參數類型
        },
        age: {
          type: graphql.GraphQLInt
        }
      },
      resolve: (parent, args, context, info) => { // 執行資料處理,args會拿到
        return `im....${args.name} age=${args.age}` 
      }
    },
    oz: {
      name: 'oz',
      type: graphql.GraphQLString
    }
  }
})
const schema = new GraphQLSchema({
  query: queryType
})
const server = new ApolloServer({ schema })

這樣就可以完全用js去建立產生schema運作

以上建立的查詢在client做以下查詢

{
  firstName(name: "oz")
  age
}

得到回應結果

{
  "data": {
    "firstName": "[oz]",
    "age": null
  }
}

api參考https://graphql.org/graphql-js/type/#graphqlobjecttype