Federation 介紹

前幾篇做了範例給大家看，不過距離30天還有一些時日，只好繼續往更深的區域來探討

在 NestJs 官網的 GraphQL 分類中有個 Federation 主題，來自於 Apollo Federation
沒有接觸過的人會有很大疑問，這是什麼，這要幹嘛，能做什麼？
接下來會先說明什麼是 Federation
然後會實際做個範例讓讀者可以更明白

以目前網頁發展趨勢，前後端功能越來越複雜。
為了解決這問題，相信很多人都聽過微服務( microservice )，我們將一個大型服務拆分成多個小服務，每個服務實現單一功能，這讓後端的架構變得更簡潔，但相對來說也是有許多技術困難。Federation 就是為了解決跨服務間的問題而產生的

Federation 主要在解決什麼問題呢？

我們先來舉個例子，以上一個範例來說，我們將原本服務封裝為 Task Service ，因為新增使用者以及留言需求，所以我們多了一個 User Service 和 Message Service

使用情境是
一個 User 可以創建多個 Task
一個 Task 可以有多個 Message
每個 Message 只對應到一個 User

這問題就來了，畫張圖給大家看

Task List	User List

以前端來說，由於每個服務的 URL 都不一樣，導致前端會因為不同的服務而需切換不同的 URL ，再來，當服務的 URL 更改時，前端也會受到影響，很顯然，這不是一個好的做法

對後端來說，以這樣的做法，只要有相關連的服務都必須知道對方的 URL

為了解決這樣的問題，Federation 提供了另一種架構
由兩種主要元件組成：一個 gateway 以及一個或多個 federated microservices
每個服務會負責該功能的 schema ，gateway 會負責合併所有的 schema ，客戶端便能直接透過 gateway 獲取所有的 scheam

Apollo Federation 目前還不支援 subscriptions.

Federation 必須遵從以下的原則

• One Graph
  在開發越來越多的 Graph 後，難免會出現重複的 Graph ，而且邏輯不一樣，這導致維護成本增高，最糟糕的是還可能導致混亂，所以應該將單一的 Graph 集中管理
• Federated Implementation
  儘管只有一個 Graph ，我們還是盡量使用 Federated 的方式，讓服務可以更為專精，更為簡潔，並且讓不同團隊能有自己的開發週期，增加團隊間的靈活性
• Track the Schema in a Registry
  應該集中管理 schema ，而不是根據不同的服務有不同的 schema

以上是針對 Apollo Federation 的解說，下一篇會帶大家實作如何使用 Federation