將多個第三方GraphQL API包裝在單個GraphQL端點中

像GitHub這樣的供應商開始提供自己的GraphQL API作爲現有REST API的替代方案。然而，許多應用程序不應該直接與這些API交談，而應該與第一方服務器進行交談，然後再與這些API交談。將多個第三方GraphQL API包裝在單個GraphQL端點中

使用REST API從一個端點代理整個第三方API是微不足道的。但是現有的GraphQL庫似乎都需要事先知道完整的GraphQL模式，似乎沒有任何方法可以指定在運行時定義的查詢或類型。

更大的問題似乎是整個GraphQL查詢將被提前解析。爲了將一個子查詢傳遞給第三方API，GraphQL片段必須被保留或重建。

下面是不起作用的例子：

new gql.GraphQLObjectType({ 
    fields() { 
    return { 
     thirdPartyApiCall: { 
     type: '???', // Type is actually defined upstream 
     resolve() { 
      // GraphQL sub-query is already parsed at this point 
      return thirdPartyGraphQLApi(graphQLSubQueryGoesHere) 
     } 
     } 
    } 
    } 
})

我想答案的一部分可能會用內省查詢產生在這個例子中type動態，一旦被載入模式時（儘管當然這意味着它不會反映上游的變化，除非經常重新生成），但是我對如何讓原始GraphQL子查詢傳遞給第三方完全喪失了信心。

這是目前可以在GraphQL中解決，而無需編寫自定義GraphQL解析器/處理程序，或者GraphQL目前不支持這種類型的委派（即直接包裝第三方GraphQL APIs）嗎？

來源

2016-09-27 Alan Plum

用戶@jbinto從GraphQL社區鬆弛有益指出我在這個目前尚未解決的問題的GitHub上graphql-js實現：https://github.com/graphql/graphql-js/issues/490

目前的答案似乎是「它不能這樣做」，但維護人員正在研究現在，GitHub創建了第一個主要的公共GraphQL API。

值得關注GitHub上這個問題的發展，看看討論中出現了什麼解決方案。未來驅動程序可能會支持這種情況，或者可能會出現一個解決此問題的用戶級解決方案。關於目前的具體情況，有很多懸而未決的問題。

來源

2016-09-27 15:42:22

將多個第三方GraphQL API包裝在單個GraphQL端點中

回答

相關問題