在业务不断发展的过程中，由于前端的发展变得越来越复杂，我们需要拆分出前端应用部分，成为一个独立开发、运行的应用，而非由后端渲染出的多页面应用。
在开发一个单页面应用的时候，我们需要了解什么呢？
1. 前端应用的MVC架构是什么？ 如何实现的？
Martin folwer 在《企业应用架构模式》介绍最初的Mvc架构的三个层次的作用
| 层次 | 职责 |
|---|---|
| 表现层 | 提供服务、显示信息、用户请求、http请求和命令行调用 |
| 领域层 | 逻辑处理，系统中真正的核心 |
| 数据层 | 与数据库，消息系统、事务管理器和其他软件包进行通信 |
在前端看来则是
| 层次 | 职责 |
|---|---|
| model | 用来获取、存放所有的对象数据 |
| view | 呈现信息给用户 |
| controller | 模型和视图之间的纽带 |
以下是通过数据劫持的代码，由于过于基础，则不暂时
2.选择怎样的前端框架，angular，react，vue如何选择？
在选择框架时，我们应考虑：
- 框架是否满足大部分应用的需求，如果不能，那么需要选择使用那个框架
- 框架是否有丰富的组件库，如果没有，我们的团队和组织是否有独立开发的能力
- 框架社区支持怎么样，在出现问题时，是否能快速方便的找到人解答
- 框架替换的成本如何隔，假设我们新框架使用B框架，我们需要学习那些新的知识？
如果目前使用的技术框架逐渐淘汰，需要选择新的框架，你作为前端负责人，如何去评估那个框架更适合我们呢？
- 团队成员能否快速掌握该框架，比如angular 上手难一些，成本较大，学习vue则非常容易上手
- 框架生态是否丰富，是否拥有我们需要的功能组件，是否可以在该组件上去扩展符合自身业务的实现
- 不同框架对现项目的浏览器环境是否支持，
- 框架后期维护成本和难度怎样？项目维护难度和周期以及代码量是成正比的，代码量越大，维护成本越高，因此需要考虑到框架的规模
- 是否以最小的代价迁移现有的项目，比如我们使用react 需要迁移到vue项目中，则需要做大量的适配
- 选择大而美，还是选择小而美的框架（大而美：如angular 提供完整的生态，react是小而美，开发项目项目需要安装其他的插件完成开发，如redux、react-facth等）
在选择UI组件或者其它库时，可以通过 caniuse.com/ 进行浏览器对比，能清晰看到该库能否正常支持浏览器的兼容
3.开发一个单页面应用时，还需要什么储备知识，脚手架、UI库、模版？
现在前端领域几乎是使用cli的方式，极少有公司自己去封装自己的脚手架，因为cli已经比较成熟，且生态比较丰富，如果你想定制化，则更有自定义
4.如何做好一个单页面应用的后台渲染？
在单页面开发中，我们需要考虑的是SEO，以往前后端没有分离都是通过服务端渲染，由服务端给爬虫返回HTML，当然现在的框架也做了这方面的解决，如nuxt.js 则能高效支持爬虫，我呢吧吧单页面服务端渲染分为三种类型：
1. 非JavaScript语言的同构渲染
同构渲染是指前后端共享模版文件，把各自的模版引擎结合数据来渲染出页面，非JavaScript语言的同构渲染是同构渲染的早期演变形式，考虑到它和node的渲染方式区别，将其独立出来 它从一个多页面应用变成一个 单页面应用，如：
当用户用搜索引擎或URL直接访问 article/12sad2时，将直接由后端返回HTML
当用户从文件到转到别的页面时，则由前端来渲染，不需要经过后端处理
当用户刷新页面，重新由后端返回渲染的HTML，在由前端处理
这种渲染有事，不需要修改现有后端技术栈就可以直接使用，缺点就是需要手动的将后端的状态同步给前端，因为这种渲染方式维护比较困难，使用非JavaScript语言来生成JSON，往往不太方便，特别是强类型的语言如Java，我们需要不断声明类型，判断是否为空等
2. JavaScript语言的同构渲染
对于前端来说，这种方式更容易上手，也更有优势，利用现有知识，外加node的基础，就可以同构渲染开发，同构渲染更有优势，react，vue都提供了renderToString的支持
但是这种渲染也有风险：
a. 服务端内存溢出的风险
b. 组件与模块需要兼容浏览器和后端Node环境
c. 提供状态的获取机制
当前需要单页面应用的服务端渲染是因为现有的搜索引擎还不够强大，如百度等还不支持，或者支持的不好，未来，一旦搜索引擎一旦支持好了吗，就不需要这么麻烦
3. 预渲染
预渲染是指预先渲染html，并针对爬虫返回特定的html，这种渲染方式并不常见，一方面是不适合数据量大的应用，另一方面是因为更新比较困难，一般做SEO的人，非常不愿意这种方式
