因为只有小徐一个人开发，所以前后端是模板引擎的合作方式。无论是页面、接口修改，都在一个项目里处理掉了，一个访问首页的接口大概是这样：
GET /home.html
Response:
<div v-for="{{Video in VideoList}}">
<VideoComponent data={{Video}}/>
</div>
小徐开发的很开心，有什么功能先后端在一个项目里，一梭子就搞完了。后来小徐招了一个前端来帮他分担工作。这位前端小伙伴只会写JS，不会Java。没法改Java项目里的模板页面。
经过沟通后他们决定前端小伙先写静态页面，写完之后把代码发给小徐，然后小徐把页面代码改成JSP模板引擎的语法。
两个人开发迭代果然快很多，网站用户变多了，又开始扩充团队。这时候小徐开始忙不过来了，前端想改个颜色都得让小徐重新发布后端项目。小徐总结了下这种视图层和接口层混在一起的方案有这么几个问题：
- 前后端职责不清晰，比如一些条件渲染、循环渲染，是js写还是java写？
- 页面样式会频繁修改发版，但是后端服务希望越少发版越好，最好一周上线一次
- 用户打开页面需要等后台数据查询完成，页面白屏时间比较长。
- 对于线上出现的展示问题，前端无法单独排障，因为前端开发的是没有动态数据的静态页面
这时候开始尝试把前端项目单独部署，小徐在线上给前端团队开了一台服务器，页面请求会被路由到这台服务器上，浏览器打开后再通过HTTP请求查询后台服务。整个请求的链路大概是这样的：
改造后前端团队效率高了很多，带来了这些好处：
- 前端可以自己修改页面逻辑、发版
- 后端开发只需要关注业务逻辑
- 首屏加载变快，甚至可以做一些骨架屏的视觉效果
- 前端开发的就是线上展示的，甚至可以写前端的单元测试了
但是同样，引入新的解决方案，总会带来一些新的问题，前后端分离后会有这些影响：
- 许多逻辑被放在前端处理，前端开发的能力要求提高
- CICD需要针对前端技术栈调整发布流程
- 渲染一个页面需要的接口变多了，后端服务压力增加
但总的来说前后端分离彻底奠定了前后端开发岗位的职责区分，并且给了前端开发岗位足够的技术上限。