問題描述GraphQL可以實(shí)現(xiàn)獲取多個(gè)資源只用一個(gè)請(qǐng)求，這個(gè)應(yīng)該是覆蓋不到所有場景的吧，很多情況下我們并不能做到一個(gè)頁面只寫一次GraphQL查詢，就可以獲取這個(gè)頁面需要的所有數(shù)據(jù)的問題出現(xiàn)的環(huán)境背景及自己嘗試過哪些方法有一種場景:一個(gè)頁面里展示的信息，info1,info2,info3，前端需要請(qǐng)求多個(gè)接口，info1對(duì)應(yīng)的接口A中的a字段，info2對(duì)應(yīng)的接口B中的b字段，info3對(duì)應(yīng)的接口C中的c字段///api/user/A{id:1111,name:'張三',a:'當(dāng)前頁面要展示的info1',b:'b'//其他字段}///api/order/B{id:2222,name:'hahah',a:'a'b:'當(dāng)前頁面要展示的info2',//其他字段}///api/system/C{id:3333,name:'hehe',a:'a'c:'當(dāng)前頁面要展示的info3',//其他字段}這個(gè)時(shí)候，稍微有點(diǎn)脾氣的前端，都會(huì)去找后端撕逼，前端A:“就這三個(gè)字段，你還讓我請(qǐng)求三個(gè)接口，你不能一個(gè)接口都返回給我嗎”，后端B：“哎，我也想啊，但是xxxxx，所以我這邊不好改，”，...最后那就這樣吧。當(dāng)然，我舉得這個(gè)例子是一個(gè)很簡單的場景，實(shí)際開發(fā)過程中要比這個(gè)還要復(fù)雜；如果使用GraphQL的話，前端自己寫查詢，這個(gè)頁面需要哪些需哪數(shù)據(jù)，后端就返回給哪些數(shù)據(jù)，這是考慮到后端所有的接口都在同一個(gè)域下面，但是一般比較復(fù)雜的系統(tǒng)，后端都會(huì)分為不同的域，用戶域，商品域，基礎(chǔ)模塊域，交易域等等，這時(shí)即使用了GraphQL也可能后端C：“你看其他都不是我負(fù)責(zé)的域，我要是自己給你封裝一個(gè)，我自己底層需要經(jīng)過xxxxx等復(fù)雜的步驟去獲取其他域的，這個(gè)很復(fù)雜，你還是直接去他哪個(gè)域去查詢吧”，有兩種方法，你就再多寫一個(gè)GraphQL自己寫一個(gè)node中間層，中間層來處理這些接口數(shù)據(jù)的聚合，換句話說，中間層來聚合成一個(gè)GraphQL查詢來返回給前端，中間層分別取調(diào)用服務(wù)端的三個(gè)接口，然后把三個(gè)接口返回的數(shù)據(jù)聚合成前端所需要的疑問就是，有沒有更好的辦法來實(shí)現(xiàn)調(diào)用一個(gè)接口查詢多個(gè)資源的問題？