将博客转移到Github Issue中

为什么？

这个网站从一开始就是为了尽可能的在提供丰富的功能的同时，尽可能地缩小部署所需要的资源，因此在初始版本最自然的选择了在本地存储（相对于网站而言）md/mdx文件。固然mdx提供了传统md文件所不支持的，比如在Markdown中直接使用React部件，但是对于我目前博客的内容而言，可能更需要的是一个更加简洁，方便的博客存储方案。

遇到的问题

说实话并不多，而且完全算是我咎由自取哈哈，将内容存放在Issue中并不是新奇的想法，Github上已经有不少专注于博客存储的解决方案，比如renatorib/github-blog，以及bufgix/github-blog，但最后还是觉得像这种比较简单的API fetch操作不如自己写在util里面，后续nextjs有什么fetch/cache/revalidate的更新也能够快速的更改。

过程中只有一个难点就是如何处理slug，因为在Github RESTAPI doc中，想要get到一个issue的内容就只能用他的“issue number”，而不是在“Get Issue List”里面获取到的每一个item id。最初想的是直接摆烂，每一个博客的slug直接就是issue number，能用，但是实在是太不优雅了。说实话到现在也没有想到什么特别完美的想法，除了在runtime中维持一个List去保存所有的博客数据...

以及另外一个还没有解决的问题，那就是如何记录每一篇博客的观看数。在最开始的博客First Blog Post中有提到过，整个博客的风格实际上是完全照搬leerob的，如果浏览他的博客的repo不难发现他的博客是用mdx来存储，但是观看量还是使用了Postgres，尽管使用数据库不是什么大忌，但可能还是叛逆心导致的不想为了一个观看量的功能而专门使用到数据库（懒）。自然的我们会想到利用Issue自带的Reaction，每一次访问的时候，发送一个increment（比方说）eye emoji的请求，从而实现观看量的记录，但是这个想法很快就被否决了，因为Github对于Issue的操作都需要注册账号，并且同一个人也只能react一次，所以到现在为止也没能想到什么比较好的解决方案。

过程中想到的一些问题

最重要的就是可用性的问题了，因为众所周知的原因Github在部分地区是禁止访问的，那么如果将访问Github API的责任交给客户端来处理就会导致内容加载不出来。这个时候服务端渲染（Server-Side-Rendering，SSR）就变得很有用了，也算是偶然发现的一个SSR的额外功能。因为SSR会将页面的渲染，内容获取等在服务端进行操作，之后将一个已经populate完的HTML页面发送给客户端，这就使得访问Github的任务将会由服务端主机来完成（我这里使用的是Vercel）而非客户端，某种意义上我们将服务端主机当作了一个代理。