Feng
Feng
此文深受 @xufei 的 [一系列博客](https://github.com/xufei/blog/issues) 影响，亦有很多引用，非常感谢。 > 客户端（Client）或称为用户端，是指与服务器相对应，为客户提供本地服务的程序。一般安装在普通的客户机上，需要与服务端互相配合运行。因特网发展以后，较常用的用户端包括了如万维网使用的网页浏览器，收寄电子邮件时的电子邮件客户端，以及即时通讯的客户端软件等。 在这里，我们说的客户端应用包含桌面浏览器和移动设备浏览器（或者其他 Web 容器）中运行的 Web App，iOS 和 Android 上的原生应用，Mac 和 tvOS 上的原生应用等等。 对于一家公司的客户端产品而言，或多或少会运行在上述的几个平台之上。而这些客户端产品中，基础的业务逻辑是相同的，稳定的。那么你肯定猜出来了，我们希望能够在多个客户端产品中，共用这部分基础业务逻辑，然后上层根据不同的平台和产品设计实 现相应的 UI 展示。 实现这个目标是比较难的，先看看 Web 前端普遍存在的情况：一个产品，不管他在初期还是成熟阶段，产品经理总会花点时间出来，整个改版，这个改动主要是在 UI 层面，当然也会涉及一部分的产品逻辑调整。这时候前端工程师就不淡定了，我是改改 UI 呢还是重构呢还是重构呢😂 此时，工程师大多会思考，如果把业务逻辑和...
2004 年，Gmail 像一个妙曼的女子来到人间，惊艳了工程师，温柔了用户。随即 Ajax 被提出来，这意味着可以在不重新加载整个网页的情况下，对网页局部进行更新。尤其是近几年，前后端分离的技术实现，犹如殷十娘神剑出鞘，彻底切断了前后端程序员的联系，只剩下了 HTTP，从此前端后台相亲相爱。 微信演出票近两个月恰好完成了一次前后端分离的实践，前端采用 React & Redux 架构实现单页面应用，后台使用 Java & GO，前后端基于 RESTful 风格的 API 通信。之所以要前后端分离，肯定是当前的架构满足不了当前的需求，我们先来看看当前的架构设计。 这是一个比较常见的 WEB 系统层级架构设计模型，微信演出票也是采用这个架构。蓝色表示前端需要做的事情，绿色表示后台需要做的事情，中间有条蓝色的线想要分隔开来，但是并不能真正分隔开，因为前端的视图模板还是需要依赖后台的模板环境。分析现有的开发流程，可以发现当中存在的协作、沟通、效率上存在的不少问题： - 后端套页面需要了解 HTML，之后仍然需要前端进行确认 - 而前端实现 View 层，需要熟悉服务端语言和架构 - 前端依赖服务端开发环境，调试、维护成本突出...