我一直想做这个很久了,似乎有了新推出的Firebase Functions Hosting Integration ……好吧,我们仍然不能完全按照我们的意愿去做。但我们可以靠近!
如果您阅读上面的帖子,您可以看到我们现在如何编辑firebase.json
重定向 URL 以指向 firebase 函数,该函数可以从存储在 firebase 中的 markdown 构建页面并将其提供给客户端。
问题是,这发生在GET
每个页面的每个请求上。这是愚蠢的(对于像典型博客这样的大部分静态页面)。我们希望静态页面可以立即可用,而无需等待函数生成任何东西(即使这发生得非常快)。我们可以通过将Cache-Control
标头设置为任意大的数字来缓解这种情况,response
如
res.set('Cache-Control', 'public, max-age=600, s-maxage=31536000');
这将告诉浏览器将结果缓存 10 分钟,但 CDN 将其缓存一年。这几乎解决了除了第一次点击之外的所有页面都需要预渲染的即时可用页面的问题,这将产生渲染成本。此外,如果 CDN 确定没有足够的流量来保证存储它,它可以驱逐您的缓存内容。
越来越近。
但我们并不完全是我们需要的地方。假设您发布了您的帖子,几天后,注意到一个错字?好吧,我认为你已经很兴奋了。除非您执行以下操作,否则您的缓存内容将在今年剩余时间内继续提供:
更改帖子的 URL - 这可能是一个坏主意,因为它会破坏任何 SEO 并破坏已经存在的页面的链接。
可能有一种方法可以强制 CDN 更新,可能是通过扩展您的“发布博客文章”流程以GET
在请求标头中包含一个带有奇怪内容的 javascript 请求,或者可能有一种方法可以随时使用 firebase 函数进行更新帖子得到更新。这就是我卡住的地方。
Firebase 使用 Google 的 Cloud Platform CDN,其中包含一种Cache invalidation机制,但我不知道这是否可以从函数中轻松获得——即使是这样,它仍然无法解决从缓存中逐出的问题。
就个人而言,我可能会使用我所描述的设置,并使用中间长度的 CDN 缓存期限限制。这击败了我目前使用(优秀的)showdown.js 向客户端发送 markdown 并在本地渲染的方法,它仍然非常快,但确实需要客户端 javascript 和一些 cpu 周期。
希望有人能解决这个问题(或者 firebase 的某个人可以将托管从功能推到下一个版本:))。如果我确定了,我会更新我的答案。