對於愛寫東西的人來說，挑一個合適的博客平臺是非常重要的。而作爲一個 Web 開發者，我們肯定都希望能夠擁有一個高度定製化的博客平臺，用以展示我們獨一無二的個性以及記錄長久以來的學習工作等。與此同時，我們也希望這個平臺可以讓我們方便地發佈內容，提供完整的點贊、留言等操作。在經歷過 Hexo，Wordpress，自行搭建服務等一系列嘗試以後，我最後選擇了以 Github issues 來作爲我的博客平臺。
博客的基本能力
對於一個合格的博客平臺來說，它主要提供了下列幾種能力：
- 個人介紹
對於個人博客來說，它首先要支持展示博主的個人介紹。這個個人介紹裏面可能包括了頭像、暱稱、聯繫方式等基本內容，能夠讓讀者能夠對這個博客的主人有一個基本的認識。 - 文章的撰寫與展示
對一個博客來說，最重要的就是它的內容，也就是裏面的文章。一個好用的博客平臺應該具備方便的撰寫文章的能力，讓夠讓用戶毫無負擔地撰寫、編輯自己的文章。此外，還必須能夠文章的信息，比如展示標題、節選、封面，創建/修改時間，評論點贊數等等。 - 歸檔能力
一篇文章的撰寫時間、內容標籤/分類等都是不同的，如何按照不同的要求對這些文章進行歸檔整理，也是考驗博客平臺的能力之一。再者，當文章數量較多的時候，添加一個搜索的功能也能大大方便讀者對博客的瀏覽。 - 博主與讀者互動的能力
僅僅只有博主一個人自嗨可能難以激發寫作的動力，如果博客能夠提供博主與讀者互動的能力，將能有效激勵博主持續創作，更能提升文章的傳播度——點贊和評論功能則是互動能力中最重要的功能之一。
經過上面的幾個點，基本可以知道一個博客平臺，其主要功能就是“展示自己，溝通外界”。在滿足這個基礎的前提下，它也應該具備方便操作，高度定製化的特點。
爲什麼不選擇其他方案
在文章的開頭我有提到，我曾經嘗試過用 Wordpress，Hexo，自行搭建服務等途徑去嘗試維護博客。但這些嘗試的結果均不合我意，最後無疾而終。歸根結底，就是不夠自由和方便。
舉個例子，Wordpress 和 Hexo 都具備搭建一個主題漂亮、功能齊全的博客的能力，但是這些都必須要在它們所制定的規則下進行。如果我想 DIY 一個主題，或者加入任何我想要的新能力，都必須仔細翻閱它們的文檔，找到對應的規則再嘗試去實現，可謂是戴着鐐銬跳舞。除此之外，要發佈新的文章，動輒就要在本地跑命令行，實在是非常不優雅。更有甚者，如果希望爲文章添加評論功能，還要費一大番周折，想必體驗過的人都懂。
至於自行搭建服務，可謂是既自由又方便，想要任何功能都可以自己實現。但這種方案最大的缺點是成本較高。對於人力成本來說，服務器數據庫配置、域名、備案等一系列操作非常煩人，甚至還要考慮告警、負載、宕機等一堆的運維問題。折騰多了，也沒什麼心思往裏面寫文章。對於金錢成本來說，買域名，買服務器也是一筆花銷，尤其是當我們某段時間文章產出特別少的時候，總覺得白養了一臺服務器……
選擇 Github issues
首先是 Github，然後纔是 issues。
作爲全球最大的代碼託管平臺，又剛剛被微軟收入麾下，其可靠程度是非常高的，基本不用擔心存放在裏面的數據會丟失（想想看國內說沒就沒的網易博客，百度貼吧等）。
在 Github 上我們可以精心編輯自己的賬戶信息，包括頭像、暱稱、郵箱、工作單位等等。
Github issues 提供了非常方便快捷的編輯能力，尤其是貼圖。它支持通過拖拽、粘貼、選擇的方式上傳圖片，圖片會存放在 https://user-images.githubuse... 這個地方，且支持外鏈——這也意味着我們可以很方便地把 issue 的內容轉載到其他的平臺。
在 Github issues 裏面，可以爲某條 issue 添加點贊、愛心等互動標籤（Reactions），也可以設置分類標籤（Labels），更可以給 issue 添加評論（Comment）。
最爲重要的是 Github 提供了一套滿足了絕大部分需求的 API，囊括了 REST 和 GraphQL 的調用方式，這纔是 Github 能夠成爲我們博客平臺的大殺器，這個接下來會詳細說明。
不難看出，Github issues 擁有着前文提及的一個博客平臺所應具備的各種能力。接下來我們將以 Github issues 作爲博客平臺的管理後端，以 API 來實現和客戶端的數據交互。
天生的前後端分離
關於 Github API 的授權和調試，可以查閱我的另一篇文章《基於 Github API 的圖牀 Chrome 插件開發全紀錄》。
我們使用 Github issues 作爲博客平臺，也就是相當於管理後端。我們在管理後端裏面撰寫文章，設置標籤，回覆評論，然後通過 API 調用把數據傳送給客戶端。
幾個比較常用的 v3 API 如下：
- 獲取登錄用戶信息（GET）
https://api.github.com/user - 獲取倉庫的 issues 列表（GET）
https://api.github.com/repos/:owner/:repo/issues - 獲取某條 issue 的評論列表（GET）
https://api.github.com/repos/:owner/:repo/issues/:issue_number/comments - 獲取某條 issue 的點贊和紅心等 reactions （GET）
https://api.github.com/repos/:owner/:repo/issues/:issue_number/reactions -
爲某條 issue 提交一條評論（POST）
https://api.github.com/repos/:owner/:repo/issues/:issue_number/commentsName Type Description body string Required. The contents of the comment. -
爲某條 issue 添加一條 reaction（POST）
https://api.github.com/repos/:owner/:repo/issues/:issue_number/reactionsName Type Description content string Required. The reaction type to add to the issue.
當然你也可以使用 v4 的 GraphQL 接口，也是非常的方便，感興趣的可以自行研究。
管理後端直接用現成的 Github issues 頁面，那麼客戶端則使用 Github 爲開發者免費提供的靜態頁面部署服務 Github pages。要使用這個服務，只需要開通一個倉庫，然後在倉庫的 Settings 裏面找到 Github pages 並打開即可，默認會以 Master 分支的根目錄作爲靜態資源目錄，我們只需要把客戶端的靜態資源直接放置在這裏就好。
開通了 Github pages 以後，便可以通過其提供的 URL 直接在瀏覽器裏訪問到博客了，而博客的數據則完全加載自 Github API。
通過已授權的接口，還允許提交評論等功能：
結語
總結一下，Github issues 提供了一個博客平臺所需的的各項基本能力，與 Github 的可靠性， API 的全面性，Github pages 的便捷性結合在一起，都非常適合作爲一個博客平臺來使用。我基於 Github issues 的個人博客也已經上線，歡迎前來體驗：
如果你也覺得不錯的話，趕快給自己也搭一個基於 Github issues 的博客吧，期待與你的交流！