為什么我選擇用 Github issues 來寫博客

gnehc 發(fā)布于2019-05-23 12:20 / 2956人閱讀

摘要：為什么不選擇其他方案在文章的開頭我有提到，我曾經(jīng)嘗試過用，，自行搭建服務(wù)等途徑去嘗試維護博客。但這些嘗試的結(jié)果均不合我意，最后無疾而終。我們使用作為博客平臺，也就是相當于管理后端。

對于愛寫東西的人來說，挑一個合適的博客平臺是非常重要的。而作為一個 Web 開發(fā)者，我們肯定都希望能夠擁有一個高度定制化的博客平臺，用以展示我們獨一無二的個性以及記錄長久以來的學習工作等。與此同時，我們也希望這個平臺可以讓我們方便地發(fā)布內(nèi)容，提供完整的點贊、留言等操作。在經(jīng)歷過 Hexo，Wordpress，自行搭建服務(wù)等一系列嘗試以后，我最后選擇了以 Github issues 來作為我的博客平臺。

博客的基本能力

對于一個合格的博客平臺來說，它主要提供了下列幾種能力：

個人介紹對于個人博客來說，它首先要支持展示博主的個人介紹。這個個人介紹里面可能包括了頭像、昵稱、聯(lián)系方式等基本內(nèi)容，能夠讓讀者能夠?qū)@個博客的主人有一個基本的認識。

文章的撰寫與展示對一個博客來說，最重要的就是它的內(nèi)容，也就是里面的文章。一個好用的博客平臺應(yīng)該具備方便的撰寫文章的能力，讓夠讓用戶毫無負擔地撰寫、編輯自己的文章。此外，還必須能夠文章的信息，比如展示標題、節(jié)選、封面，創(chuàng)建/修改時間，評論點贊數(shù)等等。

歸檔能力一篇文章的撰寫時間、內(nèi)容標簽/分類等都是不同的，如何按照不同的要求對這些文章進行歸檔整理，也是考驗博客平臺的能力之一。再者，當文章數(shù)量較多的時候，添加一個搜索的功能也能大大方便讀者對博客的瀏覽。

博主與讀者互動的能力僅僅只有博主一個人自嗨可能難以激發(fā)寫作的動力，如果博客能夠提供博主與讀者互動的能力，將能有效激勵博主持續(xù)創(chuàng)作，更能提升文章的傳播度——點贊和評論功能則是互動能力中最重要的功能之一。

經(jīng)過上面的幾個點，基本可以知道一個博客平臺，其主要功能就是“展示自己，溝通外界”。在滿足這個基礎(chǔ)的前提下，它也應(yīng)該具備方便操作，高度定制化的特點。

為什么不選擇其他方案

在文章的開頭我有提到，我曾經(jīng)嘗試過用 Wordpress，Hexo，自行搭建服務(wù)等途徑去嘗試維護博客。但這些嘗試的結(jié)果均不合我意，最后無疾而終。歸根結(jié)底，就是不夠自由和方便。

舉個例子，Wordpress 和 Hexo 都具備搭建一個主題漂亮、功能齊全的博客的能力，但是這些都必須要在它們所制定的規(guī)則下進行。如果我想 DIY 一個主題，或者加入任何我想要的新能力，都必須仔細翻閱它們的文檔，找到對應(yīng)的規(guī)則再嘗試去實現(xiàn)，可謂是戴著鐐銬跳舞。除此之外，要發(fā)布新的文章，動輒就要在本地跑命令行，實在是非常不優(yōu)雅。更有甚者，如果希望為文章添加評論功能，還要費一大番周折，想必體驗過的人都懂。

至于自行搭建服務(wù)，可謂是既自由又方便，想要任何功能都可以自己實現(xiàn)。但這種方案最大的缺點是成本較高。對于人力成本來說，服務(wù)器數(shù)據(jù)庫配置、域名、備案等一系列操作非常煩人，甚至還要考慮告警、負載、宕機等一堆的運維問題。折騰多了，也沒什么心思往里面寫文章。對于金錢成本來說，買域名，買服務(wù)器也是一筆花銷，尤其是當我們某段時間文章產(chǎn)出特別少的時候，總覺得白養(yǎng)了一臺服務(wù)器……

選擇 Github issues

首先是 Github，然后才是 issues。

作為全球最大的代碼托管平臺，又剛剛被微軟收入麾下，其可靠程度是非常高的，基本不用擔心存放在里面的數(shù)據(jù)會丟失（想想看國內(nèi)說沒就沒的網(wǎng)易博客，百度貼吧等）。

在 Github 上我們可以精心編輯自己的賬戶信息，包括頭像、昵稱、郵箱、工作單位等等。

Github issues 提供了非常方便快捷的編輯能力，尤其是貼圖。它支持通過拖拽、粘貼、選擇的方式上傳圖片，圖片會存放在 user-images.githubusercontent.com 這個地方，且支持外鏈——這也意味著我們可以很方便地把 issue 的內(nèi)容轉(zhuǎn)載到其他的平臺。

在 Github issues 里面，可以為某條 issue 添加點贊、愛心等互動標簽（Reactions），也可以設(shè)置分類標簽（Labels），更可以給 issue 添加評論（Comment）。

最為重要的是 Github 提供了一套滿足了絕大部分需求的 API，囊括了 REST 和 GraphQL 的調(diào)用方式，這才是 Github 能夠成為我們博客平臺的大殺器，這個接下來會詳細說明。

不難看出，Github issues 擁有著前文提及的一個博客平臺所應(yīng)具備的各種能力。接下來我們將以 Github issues 作為博客平臺的管理后端，以 API 來實現(xiàn)和客戶端的數(shù)據(jù)交互。

天生的前后端分離

關(guān)于 Github API 的授權(quán)和調(diào)試，可以查閱我的另一篇文章《基于 Github API 的圖床 Chrome 插件開發(fā)全紀錄》。

我們使用 Github issues 作為博客平臺，也就是相當于管理后端。我們在管理后端里面撰寫文章，設(shè)置標簽，回復(fù)評論，然后通過 API 調(diào)用把數(shù)據(jù)傳送給客戶端。

幾個比較常用的 v3 API 如下：

獲取登錄用戶信息（GET） api.github.com/user

獲取倉庫的 issues 列表（GET） api.github.com/repos/:owne…

獲取某條 issue 的評論列表（GET） api.github.com/repos/:owne…

獲取某條 issue 的點贊和紅心等 reactions （GET） api.github.com/repos/:owne…

為某條 issue 提交一條評論（POST） api.github.com/repos/:owne…

Name	Type	Description
body	string	Required. The contents of the comment.

為某條 issue 添加一條 reaction（POST） api.github.com/repos/:owne…

Name	Type	Description
content	string	Required. The?reaction type?to add to the issue.

當然你也可以使用 v4 的 GraphQL 接口，也是非常的方便，感興趣的可以自行研究。

管理后端直接用現(xiàn)成的 Github issues 頁面，那么客戶端則使用 Github 為開發(fā)者免費提供的靜態(tài)頁面部署服務(wù) Github pages。要使用這個服務(wù)，只需要開通一個倉庫，然后在倉庫的 Settings 里面找到 Github pages 并打開即可，默認會以 Master 分支的根目錄作為靜態(tài)資源目錄，我們只需要把客戶端的靜態(tài)資源直接放置在這里就好。

開通了 Github pages 以后，便可以通過其提供的 URL 直接在瀏覽器里訪問到博客了，而博客的數(shù)據(jù)則完全加載自 Github API。

通過已授權(quán)的接口，還允許提交評論等功能：

結(jié)語

總結(jié)一下，Github issues 提供了一個博客平臺所需的的各項基本能力，與 Github 的可靠性， API 的全面性，Github pages 的便捷性結(jié)合在一起，都非常適合作為一個博客平臺來使用。我基于 Github issues 的個人博客也已經(jīng)上線，歡迎前來體驗：

jrainlau.github.io/#/

如果你也覺得不錯的話，趕快給自己也搭一個基于 Github issues 的博客吧，期待與你的交流！