第一步部分：后端（因为笔者是做后端的所以放在第一个），前后端的后端分两个部门。

业务处理：里面包含model，算法，业务逻辑，网络通信，多线程，多进程。

web服务器：使用任何能返回json和二进制的数据类型的框架就行。此时不再去控制前端页面的跳转了。

第二部分：api文档服务器。api文档是作为连接后端和前端的桥梁。他定义了各种api文档的请求方式和返回数据的类型。文档室友后端的人员编写。前端根据文档模拟请求数据。最难的地方在于，随着后台的开发，api的接口会进行改变，增加修改删除或者返回的数据发生变化，这些都是不可避免的。那么api的版本问题就给前端带来了问题，明明昨天请求还是OK的，今天就挂了，没有正确的数据，也会影响前端的开发进度。

有人会说放在word或者excel里面文档，那后端每开发或改动一个新功能，都要给前端一份新的api的文档，我们做的就是软件，追求的是效率，岂能容忍这种低效率的事情。

建议自行搭建一个api文档服务器：每一个API文档能够非常容易的定义请求和响应数据结构，最好能够自动生成请求和响应示例，更重要的是，生成的示例必须看起来是符合业务需求的真实数据；支持api版本发布；自动创建版本历史记录，同时要能够非常方便的查看历史版本；能够通过WEB浏览器访问；树形目录结构，方便阅读和搜索；

第三部分：前端（笔者前端功底还是比较薄弱的）：这里的前端是可以独立的，没有后端也能访问，只是获取不到后端数据。既然可以单独访问也就是说他有自己的web服务器，一般webpack和node.js构建起服务器。那么他如何和后端数据进行通信的？当然是通过api文档文档服务器里面的api描述进行数据请求。前端同时控制页面的跳转。

此时会有一个问题，前端和后端都是独立的，那么如何保证他们之间的通信的安全性？

解决方案：基于oauth2的通信，对返回数据进行加密（用AES加密数据，用RSA加密AES的秘钥）