如果這是第二次看到我的文章，歡迎訂閱z哥的公眾號（跨界架構師）哦~
每周五11：45 按時送達。當然了，也會時不時加個餐～
一、Graphql是什么
最近在折騰使用Github api做個微信小程序練練手，本篇文章就是在這個過程中記錄。
直接先看下GraphQL的語法風格，感受一下：
query {
? repository(owner:"octocat", name:"Hello-World") {
? ? ? id
? }
}
這是最最最簡單的一個運用示例，效果上等價于http://graphqlapi.xxx.com/query/repository?owner=octocat&name=Hello-World ，返回的內容格式是這樣：
{
? "data": {
? ? "repository": {
? ? ? "id": "MDEwOlJlcG9zaXRvcnkxMjk2MjY5"? ? }
? }
}
再看下稍微復雜點的查詢方式：
query {
? repository(owner:"octocat", name:"Hello-World") {
? ? issues(last:20, states:CLOSED) {
? ? ? edges {
? ? ? ? node {
? ? ? ? ? title
? ? ? ? ? url
? ? ? ? ? labels(first:5) {
? ? ? ? ? ? edges {
? ? ? ? ? ? ? node {
? ? ? ? ? ? ? ? name
? ? ? ? ? ? ? }
? ? ? ? ? ? }
? ? ? ? ? }
? ? ? ? }
? ? ? }
? ? }
? }
}
????????這是一個多級對象嵌套的查詢，這里就不繼續(xù)展開了。關于egde和node在下文會有少許講解。對GraphQL有興趣進行更深入了解的可以自行研究學習，我自己也是剛入門，不坑大家了：），官網(wǎng)是http://graphql.org/（這個可能打不開，可以打開國內的地址http://graphql.cn），F(xiàn)acebook發(fā)布的規(guī)范在http://facebook.github.io/graphql/October2016/。
GraphQL 既是一種用于 API 的查詢語言也是一個滿足你數(shù)據(jù)查詢的運行時。GraphQL 對你的 API 中的數(shù)據(jù)提供了一套易于理解的完整描述，使得客戶端能夠準確地獲得它需要的數(shù)據(jù)，而且沒有任何冗余，也讓 API 更容易地隨著時間推移而演進，還能用于構建強大的開發(fā)者工具。
二、.net下如何運用GraphQL
????????由于我需要做一個定時任務將github上的數(shù)據(jù)定時拉到本地，所以自然的選擇了后端處理的方式。找了一下.net下的GraphQL客戶端，用了這個graphql-client。代碼如下：
varheroRequest =new GraphQLRequest
? ? ? ? ? ? ? ? {
? ? ? ? ? ? ? ? ? ? Query = graphql? //這里填寫query的內容。
? ? ? ? ? ? ? ? };vargraphQLClient =newGraphQLClient("https://api.github.com/graphql");graphQLClient.DefaultRequestHeaders.UserAgent.Add(new ProductInfoHeaderValue("Safari", "537.36"));
//上面這行很關鍵，UserAgent一定要寫上，要不然會出現(xiàn)403錯誤，花了好久才找到這個問題。
graphQLClient.DefaultRequestHeaders.Add(
"Authorization","bearertoken");? //這里的token是個占位，實際需要在Github上生成。vargraphQLResponse = graphQLClient.PostAsync(heroRequest).Result;
關于token的生成以及其它的一些環(huán)境準備工作，在github上有詳細的描述，參見：https://developer.github.com/v4/guides/forming-calls/#authenticating-with-graphql。
重要的事情說3遍：UserAgent一定要寫上！！?UserAgent一定要寫上?。?UserAgent一定要寫上??！
三、運用GraphQL調用Github api
????????Github提供的API和相關文檔在https://developer.github.com/v4/?右側的目錄樹上，這次筆者需要拉取github的大量repository庫，所以用到的search接口（但是很奇怪，這個接口在文檔中并沒有列出來，也不知道為什么）。建議大家可以先在Github提供的explorer中先測試和驗證，OK了在把代碼寫到實際的項目中。
接著，筆者在實現(xiàn)自己需要的功能時又學習了2個概念，才能正常開展下面的工作。第一個是edge與node的概念，edge可以理解為一個分頁對象，其中除了包含實際的數(shù)據(jù)外還有一個cursor（返回的每條數(shù)據(jù)的唯一標識，如果要分頁的話用得到這個數(shù)據(jù)，配合before與after關鍵字來使用）字段，實際數(shù)據(jù)就是用node表示的。
????????另外GraphQL是強類型的，所以當筆者用到的search返回的結果并不是一個明確的數(shù)據(jù)對象時，先需要通過node下的__typename字段來獲得實際的對象是什么。代碼如下：
query {
? search(query:"language:c#",type:REPOSITORY,first:1){? ? edges{? ? ? cursor,? ? ? node{__typename}? ? }? }}
得到的結果是：
{
? "data": {
? ? "search": {
? ? ? "edges": [
? ? ? ? {
? ? ? ? ? "cursor": "Y3Vyc29yOjE=",
? ? ? ? ? "node": {
? ? ? ? ? ? "__typename": "Repository"? ? ? ? ? }
? ? ? ? }
? ? ? ]
? ? }
? }
}
????????得到的實際的數(shù)據(jù)對象是Repository之后，通過查閱Github Api的文檔得到該對象有哪些字段，并且從中選擇需要的字段即可。這個就是GraphQL的設計天然優(yōu)勢之一，按需獲取。單在接下去運用的時候又需要引入一個新的概念fragment，這個可以理解為一個模板，通過這個模板來向服務端指明需要獲取的數(shù)據(jù)字段。代碼如下：
fragment repFragment on Repository {
? name,
? forkCount,
? url,
? createdAt,
? updatedAt,
? licenseInfo{? //對象嵌套
? ? nickname? ? //licenseInfo的nickname字段
? },
? stargazers{? //對象嵌套
? ? totalCount? //stargazers的totalCount字段
? }
}
query {
? search(query:"language:c#",type:REPOSITORY,first:100){
? ? edges{
? ? ? cursor,
? ? ? node{
? ? ? ? __typename
? ? ? ? ...repFragment
? ? ? }
? ? }
? }
}
? 好了，這樣就得到我需要的結果了。
下面附上筆者做的Demo：https://github.com/ZacharyFan/GitHubRanking，其中的token在配置文件中自行替換即可。
四、結語
????????最后附帶提一下，GraphQL的出現(xiàn)，主要的場景還是在于賦能前端開發(fā)，賦予了前端開發(fā)者自由組織和定制請求數(shù)據(jù)的能力。這是一個將前后端分離后的界限偏向前端的框架，所以直接在前端通過GraphQL訪問后端數(shù)據(jù)是個人比較推崇的方式。目前前端非?；馃岬腉raphQL框架也不少，主流的就是下面2個：apollo（https://github.com/apollographql/apollo-client）、relay（https://github.com/facebook/relay）。
GraphQL雖好，但是要真正在中大型項目中運用GraphQL，還有有很大的困難的，服務端需要支持到GraphQL的規(guī)范格式進行數(shù)據(jù)輸出，我認為需要付出的成本可不小。哪怕的架設一層中間層，也需要解決諸如分發(fā)、聚合和性能等問題。
?作者：Zachary（個人微信號：Zachary-ZF）
微信公眾號（首發(fā)）：跨界架構師。<-- 點擊查閱近期熱門文章
如果你是初級程序員，想提升但不知道如何下手。又或者做程序員多年，陷入了一些瓶頸想拓寬一下視野。歡迎關注我的公眾號「跨界架構師」，回復「技術」，送你一份我長期收集和整理的思維導圖。
如果你是運營，面對不斷變化的市場束手無策。又或者想了解主流的運營策略，以豐富自己的“倉庫”。歡迎關注我的公眾號「跨界架構師」，回復「運營」，送你一份我長期收集和整理的思維導圖。
定期發(fā)表原創(chuàng)內容：架構設計丨分布式系統(tǒng)丨產(chǎn)品丨運營丨一些深度思考。
掃碼加入小圈子??
