我想了解GraphQL最適合在微服務體系結構中使用的位置。GraphQL和微服務體系結構
關於只有1個GraphQL模式作爲API網關代理到目標微服務的請求並強制響應，存在一些爭議。微服務仍然會使用REST/Thrift協議來進行通信思想。
另一種方法是每個微服務都有多個GraphQL模式。擁有一個較小的API網關服務器，可將請求路由到目標微服務，並提供請求的所有信息+ GraphQL查詢。
1日法
有1 GraphQL模式爲API網關會在那裏每次你改變你的微服務合同的輸入/輸出一個缺點，我們必須相應地改變GraphQL架構上API網關側。
第二個方法
如果使用每個微服務多GraphQL架構，有意義的方式，因爲GraphQL強制執行模式定義，而消費者將需要尊重從微服務給定的輸入/輸出。
問題
你在哪裏找到GraphQL正確的適合設計微服務架構？
您將如何設計一個可能的GraphQL實現的API網關？
絕對方法＃1。
讓您的客戶與多個GraphQL服務對話（如方法＃2）完全違背了首先使用GraphQL的目的，即在您的應用程序數據上提供一個架構，以允許在單程往返。
有一個無共享架構似乎從微服務的角度合理，但對於你的客戶端代碼這是一個絕對的噩夢，因爲每次你改變你的微服務的一個時間，你必須更新的所有你的客戶。你一定會後悔的。
GraphQL和微服務是一個完美的選擇，因爲GraphQL隱藏了一個事實，即您擁有來自客戶端的微服務架構。從後端角度來看，您希望將所有內容分解爲微服務，但從前端角度來看，您希望所有數據都來自單個API。使用GraphQL是我知道的最好的方式，可以讓你同時做到這一點。它可以讓你將後端分成微服務，同時還爲所有應用程序提供單一的API，並允許跨不同服務的數據進行連接。
如果你不想爲你的微服務使用REST，你當然可以讓它們每個都有自己的GraphQL API，但是你仍然應該有一個API網關。人們使用API網關的原因是爲了更方便地從客戶端應用程序調用微服務，而不是因爲它適合微服務模式。
有關微服務的更多信息，我認爲GraphQL也可以在無服務器體系結構中完美工作。我不使用GraphQL，但我有my own similar project。我將它用作aggregator，它調用並將許多函數集中到單個結果中。我認爲你可以對GraphQL應用相同的模式。
對於方法＃2，實際上這是我選擇的方式，因爲它比手動維護惱人的API網關要容易得多。通過這種方式，您可以獨立開發您的服務。讓生活變得更容易：P
有一些很好的工具可以將模式合併爲一個模板，例如graphql-weaver和apollo的graphql-tools，我使用的是graphql-weaver，它很容易使用，效果很好。
由於微服務架構沒有合適的定義，因此沒有針對這種風格的特定模型，但其中大多數模型將具有幾個顯着特徵。在微服務架構的情況下，每個服務可以分解爲單個小組件，可以單獨進行調整和部署，而不會影響應用程序的完整性。這意味着您只需更改一些服務，而無需通過自定義microservices app development進行應用程序重新部署。
請參閱文章here，其中說明了方法＃1如何以及爲什麼更好地工作。請參閱本文采取下面的圖片： 
下面的文章也值得一提：https://nordicapis.com/7-unique-benefits-of-using-graphql-in-microservices/
+1我應該把我的後一個聲明，我沒有與GraphQL經驗，而不是響應基於在回答這個問題的研究過程中閱讀一小段簡短的內容。我認爲這個答案更好地解決了OP的查詢。 –
@helfer：這真的很有意義:)謝謝。我在這個美妙的答案之上有幾個問題。 - 您是說GraphQL必須用作API網關？ - 假設我有一個** Order ** Microservice，它暴露了REST或GraphQL端點。一旦我完成它，我不得不更新主要GraphQL模式以反映與微服務將暴露的完全相同的數據？它是不是聽起來不重複，或者離開應該獨立部署的微服務文化？對微服務的任何更改都必須反映/複製到主GraphQL架構？ – Fabrizio
@Fabrizio GraphQL的好處在於即使後端REST API發生變化，只要有一種方法可以獲取REST服務先前公開的數據，GraphQL模式仍然可以保持不變。如果它暴露更多的數據，那麼處理這個問題的規範方法就是將新的字段/類型添加到現有的模式中。 Facebook創建GraphQL的人告訴我，他們在四年內從未對他們的模式做過任何改變。他們所做的所有更改都是附加的，這意味着新客戶可以使用新功能，而老客戶可以繼續工作。 – helfer