Web 技术研究所

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

前端服务化

  如果项目是完全前后端分离的,那么前端无非就是一些静态文件而已。如果有一个对外的静态文件的存储服务,那就意味着前端项目的部署根本不需要申请机器。这样的服务还真有,比如 CDN 就是一个非常好的东西。如果前端的发布可以直接与 CDN 对接,那就不再需要机器。
  但其实现在很多前端项目所谓的单页应用依然需要后端支持,它们的实现是将所有 URL 都指向同一个 html 文件,然后由前端来分析路由。然而「将所有 URL 都指向同一个 html 文件」这个行为实际上是后端行为。也许 http 服务器可以搞定,但这已经属于人为干预的后端行为了。自然状态下,URL 和文件系统本来就有一套对应原则。如果前端可以满足这个规则,CDN 之类的各种静态文件服务器都可以直接作为前端的发布平台使用。

  1. 不要使用路径传参数,改用 hash
  比如原来是 /articles/233/comments 这样的路径,应该改成类似 /article-comments#!articleid=233 这样。这样可以将所有这类路由和服务器的文件系统对应起来。

  2. 把 QueryString 转换成 hasn
  比如原来是 /article-comments?articleid=233 这样的路径,应该改成类似 /article-comments#!articleid=233 这样。这样 CDN 节点就可以不需要做多余的回源操作,也避免了不必要的缓存。

  3. 跨域调 API
  很多前后端分离的项目虽然逻辑上确实是前后端分离,但所有流量依然从前端的域名进入,后端 API 服务器不对外暴露。这种情况下前端的 http 服务器就需要对特定的路由代理到 API 服务器上。如果把后端 API 的 http 服务直接对外,并绑定上域名,前端直接跨域调用这个 API 就可以避免前端的 http 服务器做一层代理。

  直到前端 http 服务器上没有任何规则,完全可以和文件系统关联后,前端项目的发布就可以直接对接 CDN 了。这样无论需要开多少前端项目,我们也只是添加 CDN 的域名绑定而已,不需要再申请机器。
  上面的 CDN 实现只是一个最节省资源的例子而已,也可以用自己的服务器集群来实现。反正前端服务化就是这么被实现了。
网名:
34.203.245.*
电子邮箱:
仅用于接收通知
提交 悄悄的告诉你,Ctrl+Enter 可以提交哦
神奇海螺
[查看全部主题]
各类Web技术问题讨论区
发起新主题
本模块采用即时聊天邮件通知的模式
让钛合金F5成为历史吧!
次碳酸钴的技术博客,文章原创,转载请保留原文链接 ^_^