从消失的书架组件说起：

如果之前也访问过这个博客的朋友应该有印象，之前的 homepage 页有一个书架栏目，里面展示了我正在阅读的一些书目，一开始我原本尝试从微信读书找接口，看看有没有能比较方便一键导出的方案，结果，微信还是一如既往的封闭生态🥲（致敬微信公众号），没有现成的方案可以使用，如果想要从这方面着手的话，还得逆向调试接口，这太麻烦了...实在懒得折腾。于是博客上的书架就一直没更新，前段时间也就顺手去掉这个组件了。

除此之外，homepage 的游戏展示组件也会有请求限额问题，由于是直接从 steam 的官方接口拉取的图片（其实现在想来完全可以下载到本地存储），steam 本身的接口请求次数有限制，与此同时，经由 vercel 的话会消耗每月的图片额度。所以不得不调高缓存时间，减少拉取次数，也就导致了有人问我："为什么在 steam 上看两周在线时长和博客页面不一样。" 答案是缓存...而且我设置的缓存过期时间还很长，于是就会出现博客上显示在线，而 steam 上却是离线的诡异对比。

请求过多即会导致

当然，我大可以设计一套 api 接口交给我的 vps 来运行请求，但我觉得这就失去了静态博客的意义（虽然接入了 supabase 之后也不能完全算静态）。所以就一直这样得过且过的放着，反正作为一个基本没什么人访问的小站点倒也足够正常运转。

基于飞书多维表格的设计：

解决方案总是在无意中遇到😂。前些天在筹备 ctf 新生赛瞎逛的时候，意外逛到了时歌大佬的博客，看到了它基于飞书多维表格的书架设计，原理大概是:

在飞书上新建多维表格，放入自己需要的信息 ->  github action 触发，通过飞书开放平台提供的 api 获取 json 信息 -> 将其存储在根目录的 public 文件里 ->  action 将对应的更改 commit 提交 -> vercel 监视到分支发生变化，触发重新构建

这是一个非常有创意的方案！

飞书的每一个云文档都有自己对应的 app_token，而在每一个云文档里建的表又具有对应的 table_id ，从而可以让每个信息做到一一对应。

这就类似于一个数据库中对应有多张表，但这个数据库是免费的云上数据库，并且表格本身的编辑相较于其余的编辑格式也轻松许多，上传编辑等功能都由飞书团队为你埋单。

所以作为一个缝合了众多风格的 blog，我就同样照抄了这一版方案，当然，添加了一些自己的实现，主要是将 blog api 聚合在一起，完善了一些类型规范检测，相较于原先的 py 脚本，基于 go 的实现能保证类型正确，不会因为奇怪的字符而引起程序崩溃。

以后的资源可以考虑直接从官方 api 直接下载，比如 steam 上的图片（当然，飞书新建一张表也只是多添加一个 table_id 然后遍历的事情）。从而可以让整个博客资源统一控制在一个地方，只要字节和微软不倒闭，那么整个流程基本是完全免费的，同时飞书本身也是一个非常好用的产品，我目前也正在将自己的笔记和知识库迁移到云文档上，不愧是一个部门一万多人...
飞书的 go sdk，设计的非常...冗长

完整实现在：https://github.com/cry0404/BlogApi ，不过这里只有拉取信息的脚本，需要结合博客本身的目录来写 github actions 的 workflow。
我会在之后一段时间把一些平台 api 接口，例如 bilibili 和 steam 补齐，工作量不是很大，也许很快就能完工。

如果你对这类实现感兴趣，也可以复用我的代码来实现一个定时更新的书架组件（其实只要动态更新的组件均可）。

一些启发：

除了本身构建自己博客组件的启发外，此次阅读时歌的博客还给了我另外的启发——产品的需求。他基于这个方案，为一个外贸电商打造了站点。

引用他在博客里提到的一句话

对于客户而言，他们获得了一个无需任何技术背景、像编辑 Excel 一样直观的内容管理后台。增删商品、更换轮播图、调整网站文案，都只是在熟悉的表格里填填改改，学习成本几乎为零。

对于我（开发者）而言，前端（Astro）与数据源（飞书）完全分离。我只需要关心如何优雅地展示 JSON 数据，而无需为内容管理系统的开发、部署和维护操心。这种分工让整个项目的迭代和维护变得异常清晰和高效。

从最初用飞书管理个人书架，到现在支撑起了一个完整的电商网站，这套飞书多维表格数据源+Github Action+Astro框架等静态站点的方案无疑展现了其高度的灵活性。它证明了我们可以利用手边成熟、易用的工具，通过一点胶水代码，创造出专业、稳定且对非技术人员极其友好的解决方案。

基于此，我目前对于市场所需要的产品又有了新的认识，除非是完全革新的角度，让大家不得不去学习新的东西来适应，不然大多数人还是会更喜欢自己平常熟悉的东西来构建，这跟我写代码偏向 go 和 rust 而不愿意去写 py 是一个道理——人都喜欢用自己熟悉的。

这也是我认为那些低代码平台注定无法普及大众的原因，例如 coze 、dify，抑或是 n8n，他们的思维依旧是程序员思维，而没有深入到最底下人的需求——我只是想编辑下 excel 、写个 word 就能得到我想要的。毕竟，大多数的学习并不是自己本身想去学习，很多时候，我们很难做到 Just Study for Fun。

注：此项目的思路来自于时歌