# 前端架构
# 在迭代0，我们所要做的基本事项有：
- 创建应用脚手架。
- 创建项目的代码库。
- 搭建持续集成、持续交付。
- 进行各种权限配置，如各种不同的环境账号准备、开发人员的账号配置等。
- 配置配套的工具，如代码审查、自动化原生应用上传等。
- 更细粒度的技术选型。
若是计划使用服务端渲染，那么我们需要准备好与Node.js相关的线上调试环境，并让团队拥有基本的调错（debug）能力。若是计划使用Docker，那么也需要不断尝试练习与DevOps相关的技能——哪怕是公司内部拥有相关的DevOps，开发人员也需要拥有基本的能力，才能应对线上的问题。
大部分应用只是单纯的静态文件，可以直接打包交给后端人员上线，也可以结合Docker进行自动化部署。若是带有服务端渲染的前端应用，部署会稍微麻烦一些，还需要配套对应的进程管理、服务监控等一系列的工具。
Graphviz就是一个不错的工具。它是一个由AT&T实验室启动的开源工具包，用于绘制DOT语言脚本描述的图形。它也提供了可供其他软件使用的库，比如Darge.js是一个可以直接在浏览器渲染Graphviz的库。
比如Dia。它是开源的流程图软件，是GNU开源计划中的一部分，
在Node.js领域里，则可以使用cnpmjs来搭建自己的私有化包服务器。
回滚机制、蓝绿部署、灰度发布
蓝绿部署是不停老版本，部署新版本然后进行测试，确认OK，将流量切到新版本，然后老版本同时也升级到新版本。
# js兼容
# 方式一
引入polyfill文件来模拟对这些API的支持，这种方式是通过为旧的浏览器添加方法来实现的。
通过polyfill的方式只能解决缺少API的问题，而当我们要使用一些新的语法特性，比如箭头函数（(参数1，参数2, …，参数N) => {函数声明 }）时，则需要使用转译的方式来实现。
# 方式二
转译（Transpiling），即通过使用Babel等编译器，来将代码编译成ES5版本的JavaScript代码。通过这种方式可以将我们使用的新API、新特性都进行转译，以实现对旧式浏览器的支持。而这种转译实际上是使用其他代码来替换相应部分的代码，比如使用一个新的find来实现替换代码中的Array.prototype.find方法，而不是提供对其的支持。
# 前后端分离的开发模式：
瀑布模式的前后端分离，仍然是预先制定API的文档，再进行联调。敏捷模式的前后端分离，则是一个业务一个API，每个API单独集成。两者之间，敏捷模式更能响应变化，瀑布模式更依赖于前期的设计能力。如果是团队内的项目，那么大抵采用的都是敏捷模式，是团队的成员所能接受的。可一旦对接第三方的API和服务，大家想要的就是瀑布模式，让第三方先把API测试好，再提供给团队使用。
代码即文档。在代码编写函数和功能的同时，也编写应用相应的文档。然后，通过诸如Javadoc、JSdoc等来生成应用的相应文档。
# 相比之下GraphQL具有下面的优势：
- 按需获取。客户端可以按自己的需要，从服务端获取已经定义好的资源和数据，而非进行与服务端BFF相关的编程。
- 代码即文档。与参数相比，GraphQL编写的查询语句更像是一份文档。换句话说，它适合于人类阅读。
- 易于使用的API调试工具。如图8-7所示，多数的GraphQL实现都能提供一个开发用的前端调试API界面，可以进行API请求、验证等。
- 强类型的API检查。面向前端的接口都有强类型的Schema做保证，能快速地定位问题。
- 易于版本化的API。其可以通过Schema扩展API，而REST则需要通过URI或HTTPheader等来接收版本。
缺点 - HTTP请求无法被缓存。由于所有HTTP的请求只能在App级别上实现缓存，即通过GraphQL客户端库来实现。
- 错误码处理不友好。GraphQL统一返回200的结果，在其中对错误信息进行包装。对于传统的HTTP客户端来说，需要额外的处理才能走到异常分支。
- 学习成本。使用GraphQL就要学习一门查询语言，同时还需要写一大堆Schema才能使用这种特定格式。从某种意义上来说，相当于学习一门数据库语言。
- 实现复杂。普通的场景下，需要开发人员编写Schema声明，手动编写Resolver来关联字段。一旦遇到复杂的场景，就会难以控制。