爲何我選擇用 Github issues 來寫博客

時間 2019-11-05

標籤爲何選擇 github issues 來寫博客欄目 Git 简体版

原文原文鏈接

對於愛寫東西的人來講，挑一個合適的博客平臺是很是重要的。而做爲一個 Web 開發者，咱們確定都但願可以擁有一個高度定製化的博客平臺，用以展現咱們獨一無二的個性以及記錄長久以來的學習工做等。與此同時，咱們也但願這個平臺可讓咱們方便地發佈內容，提供完整的點贊、留言等操做。在經歷過 Hexo，Wordpress，自行搭建服務等一系列嘗試之後，我最後選擇了以 Github issues 來做爲個人博客平臺。react

博客的基本能力

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

我的介紹對於我的博客來講，它首先要支持展現博主的我的介紹。這個我的介紹裏面可能包括了頭像、暱稱、聯繫方式等基本內容，可以讓讀者可以對這個博客的主人有一個基本的認識。github
文章的撰寫與展現對一個博客來講，最重要的就是它的內容，也就是裏面的文章。一個好用的博客平臺應該具有方便的撰寫文章的能力，讓夠讓用戶毫無負擔地撰寫、編輯本身的文章。此外，還必須可以文章的信息，好比展現標題、節選、封面，建立/修改時間，評論點贊數等等。數據庫
歸檔能力一篇文章的撰寫時間、內容標籤/分類等都是不一樣的，如何按照不一樣的要求對這些文章進行歸檔整理，也是考驗博客平臺的能力之一。再者，當文章數量較多的時候，添加一個搜索的功能也能大大方便讀者對博客的瀏覽。後端
博主與讀者互動的能力僅僅只有博主一我的自嗨可能難以激發寫做的動力，若是博客可以提供博主與讀者互動的能力，將能有效激勵博主持續創做，更能提高文章的傳播度——點贊和評論功能則是互動能力中最重要的功能之一。api

通過上面的幾個點，基本能夠知道一個博客平臺，其主要功能就是「展現本身，溝通外界」。在知足這個基礎的前提下，它也應該具有方便操做，高度定製化的特色。瀏覽器

爲何不選擇其餘方案

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

舉個例子，Wordpress 和 Hexo 都具有搭建一個主題漂亮、功能齊全的博客的能力，可是這些都必需要在它們所制定的規則下進行。若是我想 DIY 一個主題，或者加入任何我想要的新能力，都必須仔細翻閱它們的文檔，找到對應的規則再嘗試去實現，可謂是戴着鐐銬跳舞。除此以外，要發佈新的文章，動輒就要在本地跑命令行，實在是很是不優雅。更有甚者，若是但願爲文章添加評論功能，還要費一大番周折，想必體驗過的人都懂。前後端分離

至於自行搭建服務，可謂是既自由又方便，想要任何功能均可以本身實現。但這種方案最大的缺點是成本較高。對於人力成原本說，服務器數據庫配置、域名、備案等一系列操做很是煩人，甚至還要考慮告警、負載、宕機等一堆的運維問題。折騰多了，也沒什麼心思往裏面寫文章。對於金錢成原本說，買域名，買服務器也是一筆花銷，尤爲是當咱們某段時間文章產出特別少的時候，總以爲白養了一臺服務器……運維

選擇 Github issues

首先是 Github，而後纔是 issues。

做爲全球最大的代碼託管平臺，又剛剛被微軟收入麾下，其可靠程度是很是高的，基本不用擔憂存放在裏面的數據會丟失（想一想看國內說沒就沒的網易博客，百度貼吧等）。

在 Github 上咱們能夠精心編輯本身的帳戶信息，包括頭像、暱稱、郵箱、工做單位等等。

Github issues 提供了很是方便快捷的編輯能力，尤爲是貼圖。它支持經過拖拽、粘貼、選擇的方式上傳圖片，圖片會存放在 user-images.githubusercontent.com 這個地方，且支持外鏈——這也意味着咱們能夠很方便地把 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） 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.

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

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

固然你也可使用 v4 的 GraphQL 接口，也是很是的方便，感興趣的能夠自行研究。

管理後端直接用現成的 Github issues 頁面，那麼客戶端則使用 Github 爲開發者免費提供的靜態頁面部署服務 Github pages。要使用這個服務，只須要開通一個倉庫，而後在倉庫的 Settings 裏面找到 Github pages 並打開便可，默認會以 Master 分支的根目錄做爲靜態資源目錄，咱們只須要把客戶端的靜態資源直接放置在這裏就好。