上圖為本專案 GraphQL schema & query definition 的截圖 本專案於空閒時間持續往前走（堅定～ # 描述 在人生休息的空檔中，好友有個想法想寫成系統，於是成了這個 Project。 CP 資料模型依照 prototype 的實作，最複雜的情況是 1 -> * -> * -> *，目前 CP 還未開始實作任何的 UI，主要是透過 API 來進行驗證。 在動手開始實作之前，選擇 Technology Stack 其實有些糾結，到底要繼續沿用馬上要變成 Jakarta EE 的 Java EE 體系呢？還是要改用基於 Java EE 延伸的 MicroProfile 呢？或者，轉向到 Spring 的陣營？甚至更破釜沈舟一點，跳出 Java 改用 Node.js 或其他語言。 考慮了許久，既然是個純興趣的 Project，就以興趣為導向吧！ 目前最有興趣的是 GraphQL，同時我也想理解 MicroProfile 到底能多 micro，所以最終選擇了 Payara Micro 5.193，以 MicroProfile 原生支援的 JPA 和 CDI 來實作 ORM 及 Business Logic，以 GraphQL 作為唯一的對外 API。 # 最有趣的技術問題 我必須誠實、雀躍地說，學習新技術是開心的～（大心 由於選定的技術除了 GraphQL 以外，並沒有和經驗有太大的落差，所以能更專注在怎麼設計／實作得更好。 除了起頭在採用 GraphQL for Java 上花了一些時間外，並沒有遇到什麼困難，只能說感謝廣大的社群，世界真的因為有您們而更美好。 實作完 API 後，最初是透過 GraphiQL 的 UI 來測試，但若要執行單元測試，就會面臨到必須採用 GraphQL Client 的問題。 一開始的想法是，感謝廣大的社群，我又要來麻煩您們了～ 但找到的框架，各有各的用法，有的還非常大，不禁讓我反思「只是為了單元測試，有必要嗎？」 最後我決定返璞歸真，從透過 Browser 來監控 GraphiQL 的 HTTP Request，研究一下到底是怎麼實現的。 結論是，GraphQL Client 和 Server 之間的溝通，並沒有脫離 HTTP 通訊協議的範疇。每個操作都包裝成了 HTTP POST，因此若是在 SSL 的情況下，比一般 RESTful API 來得安全，而 POST 的 payload 也不複雜。 所以 => 最終我以 Java 11 中的 HttpClient 加上 MicroProfile 中的 JSON-P，自己實作了簡易版的 GraphQL Client for Java，實際上效果還不賴！（笑～ # 感想 假如哪天我有幸可以再成為選定技術的決策者， ㄧ、真的會優先評估採用 GraphQL 作為 API Layer； 二、MicroProfile 的標準規範，依照目前 prototype 來看，若純粹開發 API，應是足夠。更甚者，完整支援 JavaEE 8 和 MicroProfile 的 Payara Micro 整包也才不到 80 MB，對於資源錙銖必較的 Cloud Computing 真的是不錯的選擇。 回頭想，以往的專案真的花了不少力氣為了各種「略有差異」的需求一再包裝 RESTful API，以目前的理解來看，若採用了 GraphQL 的確可以有效減少這類重複作業及維護，研發人員應該會開心很多吧～ # 技術 - Application Server｜Payara Micro 5.193 - Programming Language｜Java, GraphQL - Framework｜Java 11, GraphQL for Java & MicroProfile including CDI, JPA and JSON-P - Version Control System｜Git with GitLab.com