静态？服务端？客户端？ 这是一个问题
因为我的博客基于 next.js，而服务端则是一个简单的服务用来对接 notionApi，所以就面临这三个问题。一开始我选择了在
getServerSideProps 请求接口，但是面对反应迟钝的notionApi 和原始的 node 服务，跳转文章详情基本需要3秒左右的等待时间，虽然这个博客基本是我自己的自娱自乐，但这也几乎是无法容忍的。骨架，需要更多骨架
后来我将请求文章详情部分的接口由
getServerSideProps 转移到了客户端，然后使用 Chakra UI 的 Skeleton 组件增加了文章详情的骨架加载动画，这样虽然会有一段骨架屏，但体验也比之前在上一级路由停留要好的多。redux 缓存下？
因为接口设计的问题，在我的博客中首页也会请求全部的文章列表，进入所有文章的列表时也会再次请求，而且当再次进入页面时还是会重复请求文章接口。
考虑到博客并不是一个经常性更新的场景，我思考把接口请求到的数据缓存到 redux 中，当数据已经存在时就不再重复请求，这样就可以实现只显示骨架屏一次，后续提供丝滑的浏览体验。但是因为防止刷新页面不刷新数据的问题，就不考虑再给他搞到 local storage 了。
node 也缓存一下子？
因为本身对服务端的实践不多，这个 node 服务其实是可以通过 next.js 的 api 来写的，但是还是被我强行拆出来用 koa 实现。然后考虑到缓存数据，就不得不提 redis，然后请教了下后端的朋友，说如果没有分布式，那当然是全局对象暴力缓存。于是在 node 服务中，所有已经请求到的数据都被缓存到了一个全局对象中，当下次再有请求时直接先返回缓存结果，再对缓存内容进行异步更新。
这里还存在一个问题是如果 node 服务重启，缓存内容也会消失，后续考虑通过读写 json 的方式，对缓存结果再次进行缓存。
service worker 呢？
next.js 中的页面在
getServerSideProps 会通过 json 的形式返回，还有就是 notion 中有提供一部分默认封面，这些请求地址比较固定的资源通过 service worker 的形式进行一次缓存，可以提高用户再次访问时的速度。