Build a Complete App with GraphQL, Node.js, MongoDB and React.js

參考連結

Frontend

GraphQL API

Database

精準資料取得
- 宣告式 (Declarative) 資料索取
- 資料只拿剛好且彈性十足
- 透過資料之間的關係連接，大幅減少來回 request 的次數
程式即文檔
- 前後端溝通成本減少
- 實現以資料需求驅動 (driven by data requirement) 的設計
- 建立文檔 (documentation) 的時間成本幾近為 0
前端控制權提升
- 過往為了因應不同的平台或是裝置而需要一套新的 API 系統
- GraphQL API 則只需要一套，其他交給前端自行決定資料索取的格式 & 方式
- 由於 GraphQL query 與回傳的資料格式幾乎相同，大大減少前端錯估資料樣貌的可能性
- 前端不再被日益複雜的架構設計綁住，開發速度大增
高度自由的實作方式
- 不預設綁任何程式語言 (language agnostic) 或是資料庫 (DB agnostic)
- 可將不同 micro service 的 GraphQL schema 串接在一起
強型別 (Strongly Typed)
- 型別錯就直接被擋下來
- 支援五種基礎型別 (Scalar Types)
- 能自定義型別如 'URL', 'TIMESTAMP', 'DATE', 'PHONE_NUMBER' 等等

優點

過於自由、規範少
- 沒有一定的實作規範，可能因為前後端對於架構的疏忽或不了解導致設計出過於複雜的 Schema
- 沒有一個成熟的 Best Practice 時，容易出現 Anti Pattern
- 不懂 GraphQL 優勢，而設計出一套「 RESTFul GraphQL 」
學習成本
- GraphQL 不是一項很難的技術，但若要應用到整個公司或架構上的話，仍需要時間推廣及謹慎的設計與討論
- 很容易一不小心陷入 RESTful API 的設計思維、埋下更多技術債
- 很多技術如效能處理、錯誤處理不吐 4XX、安全性等等都需要額外的學習
仍是一種新技術（？）相關社群仍在開發中
- GraphQL 目前還算是新的技術、仍有許多的規範及應用仍在開發中，所以需密切注意更新，不然哪一天睡覺起來發現有 breaking change 可不是開玩笑的
- GraphQL API 主要使用 POST + json body ，所以原生不支援 multiple-part 上傳檔案
  目前僅 Apollo Server 使用 streaming 方法來達到類似效果
目前最有名的開源社群非 Apollo 莫屬，有興趣可參考看看
Server Side Caching 實作困難
- RESTful API 的 endpoint 固定且資料需求單純，然而 GraphQL 難以保證每次 request 的模樣，因此較難實作 Caching (但還是有方法！)

缺點

GraphQL 如何運作？

Client

Server

Post/graphql

One Single Endpoint

A GraphQL Query

{
query {

user {
name

age

}

Operation Types

Query

Mutation

GET

POST, PUT, PATCH, DELETE

Subscription

Set up realtime connection via Web sockets