前后端分离项目实践
本文转自:http://jiangxiao-2000.iteye.com/blog/2219921
一、前言
对nodejs有了些准备,希望多了解些后端知识,恰逢公司项目调整,分析了前后端分离的优劣,也做了一个完整的demo演示,同事都觉得靠谱,用了两个版本的时间,将公司主站项目用nodejs实现了前后端分离,在此和大家分享下,以求共同进步。案例参见 www.upopen.cn
二、为何做分离
1、开发体系:架构体系决定了后端重于前端,前端做好静态页后,要转为php或vm等,开发要用eclipce等后端环境工作,一大堆让前端迷糊的配置,一旦java人员更新了错误的文件,会导致所有人的环境启动不了,束手无策,只能等待救援。
2、难维护:页面总是会有php\jsp等非前端代码,相互干扰、无法优化,时间越久问题越突出。
3、前后端职责不清晰。
有人会问,分离为什么不全部走ajax,页面就不需要任何服务端语言了。但实际场景并非如此,首先有些数据总是要生成页面时就已经同步获取的,且全异步对SEO不利、纯html页面没有include功能等。
网上还有其它的理解,大致相同就不列举了。
三、如何做分离
1、产品设计确定后,前后端人员共同制定开发接口,为方便接口的制定、显示、测试,使用nodejs+mongodb开发了接口平台。参见http://www.upopen.cn:8090/interface/index
功能:制定接口时就直接在interface平台上新增录入ActionName、description、 method、 param 及 默认值 等并保存到mongodb,当后台开发完成后,直接用在该页面做接口测试,成功后方可交付,避免联调过程中的接口反复。(原本想用interface.upopen.cn 来测试同域名下的项目,但因cookie在不同二级域名下无法共享的问题,暂用了二级目录,不过已有方案,后续优化)
2、从前端角度考虑系统架构图如下:
-
访问入口 NGINX 代理静态资源到 STATIC 服务器,其它请求则到 NODEJS。
-
页面请求NODEJS直接render,数据相关NODEJS则做预处理,再发到后台
-
前端据已定义的接口,通过nodejs+mysql模拟后台完成数据存取,此处会增加些工作量,但只是为了走通业务流程,模拟后台数据表定义及逻辑无需严谨,只要能正常存取即可,如注册用户save to DB,登录验证read from DB,所以提供模式化的工具、写法后,新增表、接口,并不会多耗时间,nginx – nodejs – 模拟后台,即可按实际使用完成所有前端工作。
-
QA单独测前端时,修改hostIP指向到测试工具。
-
Java开发完成后接口,在 Interface平台 上验证所有接口,确认无误。QA也可以通过Interface测试Java接口
-
nodejs修改config里的hostIP配置到java,理想情况下,修改此步配置即完成联调
每个模块的简略部署如下:
Nginx.conf:
Location ~ \.(jpg|png|css|js ){ //静态资源代理
Root /root/static/;
}
Location \{ //其它接口转发
Proxy_pass http://upopen.cn;
}
…
Upsteam upopen.cn{
Server http://node.upopen.cn;
}
STATIC 结构如下:使用require.js做模块化加载工具,有朋友问为什么不用seajs,还问这两个优劣,其实前两年的项目用的都是seajs,此处想试试amd vs cmd,所以就用了require.js ,以目前的使用来看,相互可替代
Core:[核心模块,主要是引入第三方必用、稳定模块]
Base.js [自定义通用函数]
Require.js
Jquery.js
Bootstrap.js
Backgone.js
Socket.io.js
I18n.js
…
Public: [业务级公共模块]
Validate.js [表单验证模块]
All.js [所有页面需要执行的业务js,如登录验证]
Zhdoc.js [国际化文本定义]
Reset.css [样式初始化]
common.css
…
Widget: [自定义组件]
Dialog: [弹框组件]
Dialog.js
Dislog.css
Imgs: [弹框组件图片]
Calendar:[日志组件]
Calendar.js
Calendar.css
Imgs: [日历组件图片]
…
Module: [业务模块]
Issue: [静态模块]
Index: [首页]
Index.js
Index.css
Imgs:
news: [新闻]
news.js
news.css
imgs:
…
User: [用户模块]
Register: [注册]
Register.js
Register.css
Imgs:
findPwd: [找回密码]
findPwd.js
findPwd.css
imgs:
…
Nodejs结构主要如下: express 框架
App.js
Package.json
Node_modules:
Routes:
Index.js – 路由入口,接收所有请求做转发,并做权限过滤、404等
Issue.js – 接收来自index.js的静态请求
User.js - 接收来自index.js的用户请求,页面请求render,数据请求转发
…
Views: [使用ejs框架,接收来自 routes 里的页面请求]
Common: [公用模块页]
Header.ejs
Footer.ejs
…
Issue: [静态模块页]
Index.ejs
News.ejs
…
User: [用户模块页]
Register.ejs
findPwd.ejs
…
Controls: [业务逻辑模块]
Config.js –公共配置模块,如hostIP、basePath等,切换环境修改此配置
User.js - 接收来自 route/user.js的数据请求,向外转发做逻辑准备
Tool.js - 封装常用函数如http.request/mailer/md5等
Redis.js - redis封装,对于单体封装内容比较多的模块,单独成立一个文件
…
Log: [日志,采用Log4js,日志是必须的,页面开发者常欠缺日志理念]
Assets: 结构、使用同 STATIC,不配置nginx时,调用此处资源,意义不大
…
Nodejs + MySql: [模拟后台模块,相对上面的模块,主要多了DB]
Db: [数据处理模块]
Mysql.js – 封装模式化数据存储接口,提供最便捷的新增表、接口的方法
按此结构完成前端所有功能,因目前项目较小,部分模块还有细分空间。
四、分离结果如何
1、开发效率更高,在联调之前,互不干扰,前端开发完成后就是实际可用的代码,不需要再转换成后台编译环境,永远不会被java / php 启动不成功所困扰。
2、部分需要前后端共同开发的功能,如文件上传,通常需要页面端与接收端都进行相关的开发配置,之前较难定位是谁配置错误,现在全部由前端完成,开发、测试都容易定位,上传成功后,只要向java发送文件保存的路径即可。
3、完全分清了前后端开发人员的职责,任一方开发完成后都可以提测,实现同步开发、测试。
4、联调非常简单,若双方接口一致,正常情况下只要修改要接口请求IP即可完成切换。
5、问题责任清晰,联调、测试、预发、上线,每个过程都难免会产生问题,前端、后端、运维三方责任边界清晰,日志中记录nodejs的请求发出,nginx请求接收与转发、java端请求接收与返回,三处任何一处断点,都能马上定位是哪方的问题。
6、前端人员有更高的权限,页面端的展示几乎全由前端实现,但之前一些配置却受制于后台,比如常见的模板功能,纯html页面虽可以通过angularjs实现模板,但实际效果却并不理想,网速差时经常会出现include部分显示后置、甚至加载不成功的情况,nodejs的ejs框架可以很好的实现这个功能。
另外,据浏览器加载不同的css以便实现浏览器兼容,之前处理通常是页面加载后,通过js判断浏览器类型,再去加载不同的css文件,影响渲染效率,并且js判断浏览器类型本身就存在兼容问题,用nodejs则可以在render前就完成该判断,直接用相应的浏览器样式做渲染
7、代码复用,验证模块,页面端与nodejs端可以直接复用
五、注意事项:
1、前端开发人员不仅需要有扎实的nodejs知识,还要有一定的服务端、运维知识,对http通信有更深层次的理解,nginx、redis、socket、buffer等技术也要掌握,多多益善。
2、开发之初对功能充分、宽裕的评估,使用初期不要用nodejs过多开发新功能。初次使用,难免会遇到很多意想不同的问题,前端开发人员本身对服务端知识有限,java人员又对nodejs语法不熟,若处理不好会导致项目延期。我原本认为redis同memcached一样就是connect + set + get,但实际开发时遇到一些考虑不周而产生的怪异问题,延长该部分开发时间,最终导致项目delay。
3、前端开发人员可尝试用linux系统开发,第一版用win7开发时,npm部分模块的安装会不顺利,如node-canvas在win7上安装需要6步,而原本在32上已配置成功了,在64位上的系统上又不成功,后来该接口暂由java实现。实际上即使配置成功了,该模块在发布服务器的linux系统上也无法使用,需要重新安装。第二版开发时,我使用了ubuntu,虽然有一定的学习成本,但对后期的效率提升十分有益,多学习一种系统操作,和运维调试时也更加主动。不过ubuntu下没有找到做PSD切图的工具,所以安装双系统更合适切换使用。
六、总结:
目前用分离方式做了两版项目,开发效率提升、协作沟通便捷上有明显优势,作为前端也学习了很多新知识、扩大影响范围,是共赢的。目前使用还较初级,要继续学习、探索。在此贴出以便和同仁共进步之。
相关推荐
使用技术: express node xtemplate mockjs modelproxy-copy
淘宝网线上应用的传统软件栈结构为 Nginx + Velocity + Java,即: 在这个体系中,Nginx 将请求转发给 Java 应用,后者处理...按照我们在前后端分离的思考与实践(二)- 基于前后端分离的模版探索一文中的思路,Veloc
关于前后端分离的方案,在《基于NodeJS的前后端分离的思考与实践(一)》中有非常清晰的解释。我们在服务端接口和浏览器之间引入 NodeJS 作为渲染层,因为 NodeJS 层彻底与数据抽离,同时无需关心大量的业务逻辑,...
痛定思痛,今天我们重新思考了“前后端”的定义,引入前端同学都熟悉的NodeJS,试图探索一条全新的前后端分离模式。 随着不同终端(Pad/Mobile/PC)的兴起,对开发人员的要求越来越高,纯浏览器端的响应式已经不能满足...
使用Node做前后端分离的开发模式带来了一些性能及开发流程上的优势, 但同时也面临不少挑战。在淘宝复杂的业务及技术架构下,后端必须依赖Java搭建基础架构,同时提供相关业务接口供前端使用。Node在整个环境中最重要...
在前后端分离的开发模式中,从开发的角色和职能上来讲,一个最明显的变化就是:以往传统中,只负责浏览器环境中开发的前端同学,需要涉猎到服务端层面,编写服务端代码。而摆在面前的一个基础性问题就是如何保障Web...
在做前后端分离时,第一个关注到的问题就是 渲染,也就是 View 这个层面的工作。 在传统的开发模式中,浏览器端与服务器端是由不同的前后端两个团队开发,但是模版却又在这两者中间的模糊地带。因此模版上面总不可...
web期末网站设计
opsadmin 是一个基于Gin-vue-admin开发的全栈前后端分离的后台管理系统,主要用于静态文件项目(php, html, nodejs),项目提测,发布,快速更新迭代升级.zip 适合学习/练手、毕业设计、课程设计、期末/期中/大作业...
基于nodejs前后端分离思考与实践 实际状况中,总是会遇到4,5页面的项目,而且这种项目也不在少数,倘若使用node以项目为单位去开发,会发现项目很多, 很难管理,而且如果前端在没有一套成熟统一js组件框架下,以后...
2. 采用前后端分离架构,易于维护和升级。 3. 提供详细的开发文档,降低学习成本。 4. 支持二次开发和定制,适应不同场景下的应用需求。 总之,本资源为微信小程序的西餐外卖系统设计提供了一个完整且可扩展的实现...
基于nodeJs vue java spring-boot docker开发的一款bbs 如果觉得不错给个star支持一下 :nerd_face: 因为写文章需要大量的时间,通过这些文章的完成,抽出时间逐渐做一些实战性的贡献 如何启动和部署 我们想做某种的...
Lin-CMS 是林间有风团队经过大量项目实践所提炼出的一套内容管理系统框架。 Lin-CMS 可以有效的帮助开发者提高 CMS 的开发效率。 Lin CMS 特点: Lin CMS 的构筑思想是有其自身特点的。下面我们阐述一些 Lin 的主要...