这篇文章主要介绍了怎么使用节点。js实现JavaScript全栈开发,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获、下面让小编带着大家一起了解一下。
1, js属于一种解释性脚本语言;2,在绝大多数浏览器的支持下,js可以在多种平台下运行,拥有着跨平台特性;3,js属于一种弱类型脚本语言,对使用的数据类型未做出严格的要求,能够进行类型转换,简单又容易上手;4,js语言安全性高,只能通过浏览器实现信息浏览或动态交互,从而有效地防止数据的丢失;5,基于对象的脚本语言,js不仅可以创建对象,也能使用现有的对象。
<强>前后端分离的背景
强”前后端分离“显然已不是什么新鲜的话题,Zakas在2013年10月份就曾发表过一篇博客《节点。js和新web前端》讨论节点背景下新时代的前端。毫无疑问,节点的出现给JavaScript语言带来了新的生机,也使得前端开发者有了更多的可能性。
前后端分离表面上看似乎是一场“圈地运动”,但实质上前后端分离是为了解决以往开发模式的一些诟病和痛点,同时也是迎合大的行业趋势的明智之举。我所在的美团酒店事业部去年7月份成立,新的业务,新的开发团队,这一切使得我们的前后端分离推进的很彻底。截至目前,前端承载的所有业务和线上服务都是基于节点,生产环境已经有近20台服务器。如此带来的全新前后端协作方式能够让专业的人做专业的事,无论前端后端都能较之前更专注在自己擅长的方面。
<强>开发模式,技术栈
传统的开发模式只需要专注在多终端的呈现上(浏览器,WebView)。而现在,浏览器只是前端的其中一环,延伸出来的还端有节点的架构,服务的运维能力等。上图是我们目前的服务架构:Nginx位于节点服务之前,用做负载均衡,服务调度,Gzip压缩等。之后便是节点服务,我们通过PM2.5进行节点服务的集群部署和负载均衡(充分利用多核优势),同时作为轻量的中间层,负责路,由控制器,视图,以及视图的渲染,数据的获取通过RESTful API的接口使用JSON格式交互。而后端则只需要负责业务逻辑,数据存储,模型,并为前端提供JSON数据即可。
这样改变之后,节点端可以进行首屏渲染等页面加载方面的优化,页面渲染出来之后后续的交互,渲染都交由浏览器端JavaScript的代码来完成,节点端的模板和浏览器端的模板大部分情况下都是相同的,所以我们需要考虑模板重用的问题。我们用榨汁机替换了表达框架默认的模板引擎,榨汁机是一个高效、轻量的前端(JavaScript)模板引擎,效率和易用是它追求的目标。除此之外,它还可以运行在节点。js环境中。通过榨汁机,可以解决节点端和浏览器端的模板,帮手复用问题。而且基于前后端分离的工程架构下,前端的代码仓库和后端隔离,前端独立负责前端静态资源文件,模板文件,控制器的维护和发布。
按照这样重新定义前后端分工之后,前端可以做的事情较以往更多了,比如微信SDK的接入,因为微信js SDK的使用需要在服务端进行签名,所以现在我们不需要后端介入,前端完全可以独立完成微信SDK的接入。此外像我们内部和商家端SSO登录逻辑的接入都完全由前端独立完成。
<>强技术选型的思考
对于前端的技术选型,我们始终保持理性,拥抱的态度。我们不会为了盲目求新而引入新的技术,技术选型是针对我们目前大团队的场景,为了解决以往协作过程中发现的一些痛点和不足,比如引入节点是为了改进前后端的工作流和效率,提升前后端的开发体验。再比如目前我们项目中采用的角,也反应是针对特定的业务场景,为了提升开发效率,增强代码的可维护性。在我们的业务应用中,面向商家,后台的一些增删改查系统,角能够显著的提升开发效率,而反应我们目前只是在面向用户的PC端项目中在做一些尝试和实践。
<>强带来的挑战
这样的分工和架构模式在给前端带来更多可能性,更多便利的同时,也带来了不小的挑战,相比传统的前端角色而言,我们需要更多的关注线上服务的状态,进程内存占用,CPU占用的详细状况,以及线上异常的监控等。在我们拥抱节点的同时,对前端的能力要求是更上一阶的。一段看起来正常的js代码,在浏览器端和在节点端两种不同的运行环境下,就可能会暴露出一些以往关注不到的问题,比如内存泄露:一个闭包或者一个用于缓存数据的对象,跟浏览器不同,节点对内存泄露十分敏感,因为线上应用有成千上万甚至百万计的流量,所以哪怕是一个字节的内存泄露也会造成内存堆积,从而导致垃圾回收过程耗时增加,应用响应缓慢,知道进程内存溢出,应用重启或崩溃。
