Web 技术研究所

我一直坚信着,Web 将会成为未来应用程序的主流

API 不开 HTTP 缓存?

  之前听公司里的后端大神说现在的 API 都是完全不开 HTTP 缓存。听到这句话我顿时嘎嘣一下就傻了。理由是缓存难以控制,如果数据出问题,缓存的脏数据会导致用户在缓存的超时周期内无法恢复。另外还有对 API 数据实时性的一些考虑等等。
  如果是传统 Web 架构,没有缓存肯定会慢到爆,而且还可能成为流量杀手。但是对于单页应用来说,其实用户的所有操作都是在一个页面中。前端程序已经做了会话级的缓存,而用户的操作流程通常都是在同一个会话中的,所以即使不依赖 HTTP 缓存也不会多次请求资源。
  「不开 HTTP 缓存」虽然听上去很荒谬,但确实也有点道理。我觉得会产生这个观点的原因在于 HTTP 缓存设计得太死。我就一直不太喜欢 HTTP 缓存,因为程序无法控制,很容易出问题。从去年夏天开始我就在考虑一套「差异化加载」的东西,虽然目前还没有成形,但核心思想就是脱离 HTTP 缓存,全走程序缓存。
  其实这个博客程序早在两年前就开始了「不开 HTTP 缓存」。但不是因为我不想开,而是因为我的 API 是基于 WebSocket 自己搞了一套 RPC,所以根本无法使用 HTTP 缓存。但没有使用 HTTP 缓存也并不代表就一定比那些使用 HTTP 缓存的差。因为当时我就考虑到缓存问题,所以把所有数据在前端使用 indexedDB 做了行粒度的缓存。现在这套缓存反而比 HTTP 缓存要有效得多。
  API「不开 HTTP 缓存」的观点我持保留意见。然而如果 API 根本不走 HTTP 的话,那它本来就无法使用 HTTP 缓存,于是就应该在前端做好程序级的缓存。我反对「前端不做任何缓存」的观点。
网名:
174.129.187.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^