前后端分离实践

早几个礼拜前,就想写这篇文章了,昨天刚刚找到一个画图的好工具https://www.draw.io(请自备梯子),今天顺势把这篇文章补了。

在遇到前端MV*框架以前,前后端分离几乎无从做起,前端仔严重依赖后端,即页面大都是服务端渲染。有时候前端们不得不去写一写后端模板代码,也因此前端代码经常被后端『侵犯』,而且模板文件冲突时有发生。前端MV*框架诞生后,至少在开发阶段前端攻城狮们可以从后端的『魔爪』里解脱出来。这里的处理方式有多种(引入线上node服务的情况暂不讨论),我实践过/即将实践的大致有这么几种:

  1. 前端代码和后端代码可以在同一个版本仓库,前端开发时本地启动后端服务,把前端代码所在目录设置为静态资源根目录,然后直接访问入口html。当然,可以把入口文件也经过后端模板输出,但是静态资源构建时就有点麻烦了。
    此方案有个很大的弊端,为了启动后端服务,本地还要搭建后端服务环境,而且万一哪个后端大神提交了影响服务的代码,前端一拉代码,就只能停滞开发了

  2. 将上述方案迁移到某台测试服务器上,本地不启动任何服务,只需一个ftp实时上传工具,可实时检测到文件内容变更,立即通过ftp上传至服务器。
    此方案对本地环境要求低了不少,但是不适合多人协作,如果每个前端都单独使用一台服务器,成本也不低(即使是虚拟机也不例外)。

  3. 前端本地启动node服务,数据请求通过node代理到后端服务。
    此方案大大降低了对后端服务的依赖,如果后端HostA不可用,就换到HostB,灵活性非常高;而且此方案构建自由度也大大提高,并且可利用gulp+browser-sync或webpack之类的工具实现watch工作流。另外,此方案前端代码不一定要和后端代码在同一版本库管理,进一步脱离后端,如果线上并未分离部署,可在部署时,将前端代码同步给后端。

  4. 算是方案3的一个变种,本地还是启动node服务,去掉方案3中的代理中间件,再另外启动一个nginx反向代理,访问nginx服务,由nginx来区分动态/静态请求,静态请求转发到本地node服务,动态请求则类似方案3转发到指定的后端。
    此方案使得本地node服务更纯粹,切更接近线上前后端分离的部署架构,还能顺便学习一下nginx!

我们线上的前后端分离架构是这样的:
front-back-seperating.png
短期内这个方式应该不会变,目前我们正在探索线上node应该怎么玩。目前线上流量还不够大,后期会把静态资源迁移至CDN。

开发阶段,每个前端开发环境是这样的,即方案3:
frontend-dev.png

接下去打算改造成方案4:
frontend-dev-next.png

前后端分离是十分有意义的,一来使前后端各司其职,提高了开发效率;二来使得前端的角色更加重要。待到Node在生产环境发挥大展身手时,前端就真的不只是前端了.