Open chaoxihailing opened 7 years ago
前后端分离在过去的两三年里,确实特别的热闹。但是我们怎么才能知道,是不是需要这样的架构呢?
页面交互是否复杂 ? 是简单的提供页面给用户浏览?或者想要支持复杂的用户操作? 是否需要搜索引擎优化?如果需要的话,那么从一开始我们就需要考虑后端渲染。 能提升开发效率吗?如果不能有效的提升开发效率,为什么要作死呢? 是否会提供 API 给 APP?如果我们已经有一个 API 提供给 APP,那么要做这件事就很容易了。如果未来会有的话,那么我们更应该尝试去分离。 前端的修改是不是非常频繁?如果不需要经常修改的话,那么这种优化便没有优势。
是否足够的安全?如果我们设计出来的架构不够安全,那么这一系列的操作都是白搭。我们怎么去存储用户数据,使用 LocalStorage 的话,还要考虑加密。采用哪种认证方式来让用户登录,并保存相应的状态? 是否有足够的技术来支撑前后端分离?有没有能力创建出符合 RESTful 风格的 API? 是否有能力维护 API 接口?当前端或者后台需要修改接口时,是否能轻松地修改。 前后端协作的成本高不高?前端和后台两个团队是不是很容易合作?是不是可以轻松地进行联调? 前后端职责是否能明确?即:后台提供数据,前端负责显示。 是否建立了前端的错误追踪机制?能否帮助我们快速地定位出问题。
我曾经有过使用 PHP 和 Java 开发后台代码的经历,仍然也主要是集中在前端领域。在这样的传统架构里,编写前端页面可不是一件容易的事。后台只会传给前端一个 ModelAndView,然后前端就要扑哧扑哧地去丰富业务逻辑。
传统的 MVC 架构里,因为某些原因有相当多的业务逻辑,会被放置到 View 层,也就是模板层里。换句话来说,就是这些逻辑都会被放到前端。我们看到的可能就不是各种 if、 else还有简单的 equal判断,还会包含一些复杂的业务逻辑,比如说对某些产品进行特殊的处理。
如果这个时候,我们还需要做各种页面交互,如填写表单、Popup、动态数据等等,就不再是简单的和模板引擎打交道了。我们需要编写大量的 JavaScript 代码,因为业务的不断增加,仅使用 jQuery 无法管理如此复杂的代码
而仅仅只是因为逻辑复杂的前端代码,无法影响大部分团队进行前后端分离——因为它没有业务价值。实际上是先有了单页面应用,才会出现前后端分离。单页面应用可以让用户不需要下载 APP,就可以拥有相似的体现。并且与早期的移动网页相比,拥有更好的体验。
如果一个前端应用只显示数据的话,那么这个应用就没有充足的理由,做成一个单页面应用——单页面应用是为了更好的交互而存在的。当我们注册、登录、购买东西时,就需要开始与表单进行处理。