手记

前端与后端的爱恨情仇——前后端的API

前言

各位小伙伴们,在国庆节的最后一天,柳猫想跟大家分享一下自己对前后端分离的一些看法~ 如有不对的地方,欢迎各位指出斧正~

前后端分离已经是业界所共识的一种开发/部署模式了。所谓的前后端分离,并不是传统行业中的按部门划分,一部分人纯做前端(HTML/CSS/JavaScript/Flex),另一部分人纯做后端,因为这种方式是不合适的:比如很多团队采取了后端的模板技术(JSP, FreeMarker, ERB等等),前端的开发和调试需要一个后台Web容器的支持,从而无法做到真正的分离(更不用提在部署的时候,由于动态内容和静态内容混在一起,当设计动态静态分流的时候,处理起来非常麻烦)。

即使通过API来解耦前端和后端开发过程,前后端通过RESTFul的接口来通信,前端的静态内容和后端的动态计算分别开发,分别部署,集成仍然是一个绕不开的问题 — 前端/后端的应用都可以独立的运行,但是集成起来却不工作。我们需要花费大量的精力来调试,直到上线前仍然没有人有信心所有的接口都是工作的。


背景

一个典型的Web应用的布局看起来是这样的: typical web application

前后端都有自己的开发流程、构建工具、测试集合等。前后端仅仅通过接口来编程,这个接口可能是JSON格式的RESTFul的接口,也可能是XML的,并且重点是后台只负责数据的提供和计算,而完全不处理展现。而前端则负责拿到数据,组织数据并展现的工作。这样结构清晰,关注点分离,前后端会变得相对独立并松耦合。

上述的场景还是比较理想,我们事实上在实际环境中会有非常复杂的场景,比如异构的网络,异构的操作系统等。 

real word application

在实际的场景中,后端可能还会更复杂,比如用C语言做数据采集,然后通过Java整合到一个数据仓库,然后该数据仓库又有一层WebService,最后若干个这样的Web Service又被一个Ruby的聚合Service整合在一起返回给前端。在这样一个复杂的系统中,后台任意端点的失败都可能阻塞前端的开发流程,因此我们会采用mock方式来解决这个问题: 

mock application

这个mock服务器可以启动一个简单的HTTP服务器,然后将一些静态的内容serve出来,以供前端代码使用。这样的好处很多:

  1. 前后端开发相对独立

  2. 后端的进度不会影响前端开发

  3. 启动速度更快

  4. 前后端都可以使用自己熟悉的技术栈(让前端的学maven,让后端的用gulp都会很不顺手)

我们往往在集成的时候才发现,本来协商的数据结构变了:

  • deliveryAddress字段本来是一个字符串,现在变成数组了;

  • price字段变成字符串,协商的时候是number;

  • 用户邮箱地址多了一个层级;

这些变动在所难免,而且时有发生,这会花费大量的调试时间和集成时间,更别提修改之后的回归测试了。

所以仅仅使用一个静态服务器,然后提供mock数据是远远不够的。我们需要的mock应该还能做到:

  1. 前端依赖指定格式的mock数据来进行UI开发

  2. 前端的开发和测试都基于这些mock数据

  3. 后端产生指定格式的mock数据

  4. 后端需要测试来确保生成的mock数据正是前端需要的

简而言之,我们需要商定一些契约,并将这些契约作为可以被测试的中间格式。 然后前后端都需要有测试来使用这些契约。一旦契约发生变化,则另一方的测试会失败,这样就会驱动双方协商,并降低集成时的浪费。

前端发现已有的某个契约中,缺少了一个address的字段,于是就在契约中添加了该字段。然后在UI上将这个字段正确的展现了(当然还设置了字体,字号,颜色等等)。但是后台生成该契约的服务并没有感知到这一变化,当运行生成契约部分测试(后台)时,测试会失败了 : 因为它并没有生成这个字段。

于是后端工程师就找前端来商量,了解业务逻辑之后,他会修改代码,并保证测试通过。这样,当集成的时候,就不会出现UI上少了一个字段,但是谁也不知道是前端问题,后端问题,还是数据库问题等。

而且实际的项目中,往往都是多个页面,多个API,多个版本,多个团队同时进行开发, 这样的契约会降低非常多的调试时间,使得集成相对平滑。

在实践中,契约可以定义为一个JSON文件,或者一个XML的payload。 只需要保证前后端共享同一个契约集合来做测试,那么集成工作就会从中受益。一个最简单的形式是:提供一些静态的mock文件,而前端所有发往后台的请求都被某种机制拦截,并转换成对该静态资源的请求:

  1. moco,基于Java

  2. wiremock,基于Java

  3. sinatra,基于Ruby

看到sinatra被列在这里,可能熟悉Ruby的人会反对:它可是一个后端全功能的的程序库啊。之所以列它在这里,是因为sinatra提供了一套简洁优美的DSL,这个DSL非常契合Web语言,我找不到更漂亮的方式来使得这个mock server更加易读,所以就采用了它。


总结

前后端分离是一件容易的事情,而且团队可能在短期可以看到很多好处,但是如果不认真处理集成的问题,分离反而可能会带来更长的集成时间。通过面向契约的方式来组织各自的测试,可以带来很多的好处:

  • 更快速的End2End测试;

  • 更平滑的集成;

  • 更安全的分离开发。

最后,祝福大家节日快乐~



1人推荐
随时随地看视频
慕课网APP