 |
| 打造自己的GraphQL！ |
 |
| SOAP的WSIL(WS-Inspection document)很類似GrapQL的Schema |
GraphQL安全性
GraphQL安全性在於後端製定的Schema，所以Client端就不能太出格進行查詢，例如SQL Injection之類的攻擊對於GrapQL來說簡直是自然免疫。GraphQL結構開發性
GraphQL結構上是以JSON做出類似SQL的查詢方式，在前端封裝也很方便，和JavaScript對XML的操作相比，JSON還是簡單很多的。GraphQL效率
GraphQL嚴格來說是一種設計規範，目前市場主要以【Apollo】和【Yoga】這兩家團隊提供GrapQL Server建置方案，基於NodeJS Web Server的好處網路上太多了，在這邊就不再贅述。GraphQL主觀評分（滿分10分）
安全性： 6 ⭐⭐⭐⭐⭐⭐開發性： 8 ⭐⭐⭐⭐⭐⭐⭐⭐
效 率： 8 ⭐⭐⭐⭐⭐⭐⭐⭐
好處很多，但還是不夠
話說前頭，SQL Server這堵高牆就在眼前，能爬上它的就是好工具。而NodeJS比較佳的使用環境是Linux，但載體是NAS，眼下最方便的就只有PHP+Apache可以選擇，但NAS的封閉環境就是和SQL SERVER無緣！
要為DB另外設計Schema這件事好像有點畫蛇添足，如果可以直接做ORM對應，就更加省事了！
雖然GraphQL很好，但不適合我使用的場合，NodeJS不是NAS預設的WebServer，同樣也不適用。
於是便興起自己刻GraphQL的念頭，開始尋找GraphQL的替代方案。
不在前端直上SQL的理由
避孕。理想目標
- 一次Request可以進行多個SQL CURD (DML)的處理，並回傳其資料結果。
- 迴避SQL Injection攻擊是安全最低標準。
- Schema自動對應Database Table。
一次Request可以進行多個SQL CURD (DML)的處理，並回傳其資料結果
這是GraphQL最吸引我的優點，所以這個項目為必要實作。前端可以直上CURD已經要承擔很大的資料人為操控風險，再增加DDL無異是找自己麻煩，DDL就輔以API處理會比較安心。又或是搭配登入權限來調整DML可控內容也可以進一步定義。
迴避SQL Injection攻擊是安全最低標準
每個DML都必須加入參數化查詢，若無參數則視為解析失敗。另外能查詢的表格以Base Table和View為限，避免使用到系統物件(sys.*)進而造成不必要的資訊洩漏。Schema自動對應Database Table
在開發初期，資料表格和欄位是經常異動的，這樣會造成頻繁修改Schema導致前後端和資料庫都必須一同調整。這功能可以專注在前端及資料庫上，加快程式產出時間。網路上的資源
NPM Json-Sql-Builder2在Github裡找到JSB，它的文件就是定義JSON和SQL轉換的結構，文件裡的範例相當直覺，概念很適合重製。
 |
| JSB的範例非常清楚好懂 |
結論
前端要使用SQL直接操作資料庫所要承擔的風險相當高，若要在安全性和開發易用性取得平衡，使用GraphQL是很棒的方案，規範有了，打造屬於自己的GQL不是夢。參考了json-sql-builder後，發現我的想法更偏向這種JSQL的設計方式，
實作結果如上圖，能做出成果感覺超棒！
沒有留言:
張貼留言