NodeJS让前端与后端更友好的分手

学问


最近“上层建筑”在兴起国学热,所以公司几个月前决定开发一款名叫“学问”的有关于国学的app。

APP的详情页面还是由web来显现具体内容,有些类似于新闻页,图文混排什么的web是最适合干这个的了,所以团队决定用WEB来实现详情页。

团队对WEB页的要求是:

  • 页面在访问后离线依然可以查看。
  • 首屏展现速度要快,不允许长时间白屏或loading。

项目现状

后端提供的都是以JSON为数据格式的API接口供Native端使用,同样提供给WEB的也是JSON格式的API接口

那么意味着WEB工作流程是

  1. 打开web,加载基本资源,如CSS,JS等
  2. 发起一个ajax请求再到服务端请求数据,同时展示loading
  3. 得到json格式的数据后再根据逻辑选择模板渲染出”DOM字符串"
  4. 将”DOM字符串”插入页面中webview渲染出DOM结构

这些步骤都由用户所使用的设备中逐步执行,也就是说用户的设备性能与APP的运行速度联系的更紧

换句话说就是如果用户的设备很低端,那么APP打开页面的速度会越慢。

如果是在PC端的浏览器中基本不成问题,因为现在浏览器性能已经非常好了。但在低端的Android机器上的webview性能可就难说了。

而且离线后还得要查看已访问过的页面,实现最好的方式就是用HTML5的离线存储技术了,但离线存储存的是整个页面的HTML及资源,不会存JSON数据

用本地数据库存把JSON数据也存下来?靠,太复杂了吧...

只能是服务端直接输出HTML结构渲染页面,而不是API输出JSON再由客户端渲染页面。

让服务端人员来写页面?


确实可以依照以前老的方式,自己写出HTML的静态页面交给服务端人员,再套上JSP或PHP服务端语言,但是..

由于服务端人员对前端HTML结构不熟悉套代码时造成各种错误经常出现。而且很难找出BUG,相信做前端的程序猿应该都体会过..

也有很多前端人员不得不开始学习JSP或PHP来应付这样的场景,全栈工程师么-_-!..

一种折中的解决方案


我看到过某些公司的某些页面,在首屏页面head的某个<script>中输出大量的JSON数据

大概是这样

<script>
     var _jsonData = [{a: 1}, {a: 2}, …];
</script>

我猜测大概是想省去首屏发起ajax请求,直接将JSON输出到页面中,由JS来完成DOM构建。

这样在一定程度上提高了首屏渲染速度,前端人员又不用去写服务端程序

我没用这种方式,因为没人管我,我就是这么任性..

Er...更激进的解决方案


关注NodeJS很久了一直没怎么用,而且NodeJS已经发展了很多年,现在大公司应用的越来越多,可以参考NodeJS应用公司列表-》

做为前端人员,NodeJS真的很容易上手,语法就是JAVASCRIPT么。

听说淘宝啊什么的前端人员已经开始用NodeJS这么做了,大公司就是先进啊。嗯,我们盛大文学也是大公司-_-!,那么上吧骚年!

用NodeJS来做为桥梁架接服务器端API输出的JSON。如图:

浏览器(webview)不再直接请求JSP的API,而是

  • 浏览器请求服务器端的NodeJS
  • NodeJS再发起HTTP去请求JSP
  • JSP依然原样API输出JSON给NodeJS
  • NodeJS收到JSON后再渲染出HTML页面
  • NodeJS直接将HTML页面flush到浏览器

这样,浏览器得到的就是普通的HTML页面,而不用再发ajax去请求服务器了。

这样做的好处:

  • app的WEB页可以实现离线存储技术
  • 页面首屏渲染更快
  • 由于NodeJS与页面在同一个域名下,所以就不用跨域了,而不用HTML5输出头信息这样的方式去实现跨域了
  • 服务端与客户端逻辑都由前端人员控制都是使用JAVASCRIPT语言,前端程序猿可以更好的控制和优化,套页面什么的不容易出错
  • 真正服务端程序人员不需要再关心页面的渲染逻辑,仅需要关心数据的处理

这样做的坏处:

  • 增加了前端人员的工作
  • 前端人员需要对服务端程序有一定的了解
  • 服务端需要架起NodeJS服务
  • 通过NodeJS架接后台服务过程中通信时间上必然有一部分损失

好在NodeJS安装比较简单,各种插件也非常丰富

项目中实际应用经验


用ExpressJS框架搭建NodeJS的WEB服务感觉棒棒哒!

真的很简单,三下两下就搞定了,我这么菜的人都行,说明真的很简单!

注意点:

页面中动态部分,如:评论,阅读人数,赞的人员等这些动态数据还是需要用ajax请求

这些动态数据需要动态的插入DOM中否则这些数据会被离线存储给缓存住,每次打开都是一样的数据不会再更新,

除非.appcache文件更新,这样肯定不合理,嗯对,就是不合理

所以那些动态数据还是可以根据原先的逻辑去直接请求JSP或PHP之类的服务端提供的API接口,当然跨域什么的就看项目需求与项目环境了。

ExpressJS中默认的模板是EJS,而浏览器中我使用的是artTemplate.js,好吧我真的喜欢artTemplate.js

一查发现artTemplate也有NodeJS版本的,就这样服务端与浏览器端都可以使用artTemplate来做为渲染模板了,可以说是无缝啊,嘿嘿

最后要说的

第一次在正式项目中使用NodeJS还是挺兴奋的,感觉前端的路子又多了一条。

第一次麻,都紧张,都快....

er..就怕由于对NodeJS的不了解最后造成致命的错误,而导致项目延期。

现在已经上线了目前只有Android版本,扫一扫即可

===================================================================

转载处请注明:博客园(池中物,王二狗)[email protected]

时间: 2024-11-20 19:47:46

NodeJS让前端与后端更友好的分手的相关文章

前端JS后端nodeJs 实现加解密; 个人理解

//说明: // 1.如果加密解密涉及到前端和后端,则这里的key要保持和后端的key一致 // 2.AES的算法模式有好几种(ECB,CBC,CFB,OFB),所以也要和后端保持一致 // 3.AES的补码方式有两种(PKS5,PKS7),所以也要和后端保持一致 // 4.AES的密钥长度有三种(128,192,256,默认是128),所以也要和后端保持一致 // 5.AES的加密结果编码方式有两种(base64和十六进制),具体怎么选择由自己定,但是加密和解密的编码方式要统////一 //

前端和后端如何合作

我们的流程是这样的,后台提供数据接口,或接口文档. 然后我们前台进行razor模板的数据逻辑嵌套或html,css,js整个流程的开发. 缺点是:工作量是满大的,优点是,所有前端view层的东西都是可控的. 坑是比较多的, 比如数据出现问题时,没有一个经验丰富的前端或后端进行联调, 有问题短时间内是解决不了的. 一般跟后台合作分为这几种模式:1. 只产出html页面,然后交给后端来处理数据.这种的好处是工作量比较少,公司没有专门的前端岗位时可以实行这种办法.但这种的缺点也是显而易见的,后端人员工

文件上传之前端和后端

明天又是星期一.发现周末的时间过得真快啊.光阴似子弹,嗖的一下,两天就没了. 文件上传是web开发中很常见的场景,比如填写个人信息的时候传一两张自己美美哒照片,比如上传一张个性的头像.有时候需要上传一个压缩包,文档啥的.作为程序员嘛,自然免不了要想办法让这些美照啊,文件啊顺利的到达服务器. 今天我来写一段最简单的文件上传.至于简单到什么程度,那我先介绍一下稍微复杂的文件上传吧. 1.web2.0时代,用户体验是web开发必须考虑的问题,文件上传自然不能跳转,所以,类Ajax的方式上传文件是现代网

前端和后端工具

工具的分享分为前端和后端工具,前面的1-7条为后台测试常用工具,最后一部分中的众多工具是前台测试工具,感谢搜索应用测试组的同学提供协助! 邮件中所列出的工具,有哪些你不知道如何使用,或者认为有必要做进一步讲解,请告知我们,我们随时倾听你的声音,并据此筹划下一步的分享,谢谢! 1. screen命令 应用场景: 当你运行一个任务,比如make一个大的项目.建立索引的时候,任务的时间很长,在这段时间如果需要断开网络连接(比如想关机.或者网络问题),你的任务将会消失.screen就可以解决这样的问题.

Linux平台上的多种软件安装方式与更友好的包管理软件介绍

一.Linux平台上软件安装卸载的四种方式 1.源码包安装.卸载 优点:性能最好,稳定 缺点:安装稍微复杂,容易出错 一般软件的源码包都进行了压缩,压缩的格式分为gz和bz(或bz2)两种格式. 源码包的格式:***.tar.gz(或bz,bz2). 如下图所示,是PHP的源码包: 源码包(以PHP的安装包为例)的安装.卸载的方法如下: 1)安装: 第一步:解压安装包 gz后缀用:tar -zxvf php-5.5.14.tar.gz bz(或bz2)后缀用:tar -jxvf php-5.5.

我们前端跟后端是怎么合作的

摘要: 文章背景,来自于群内周五晚上的一次头脑风暴式的思维碰撞交流活动. 我们的流程是这样的,后台提供数据接口,或接口文档. 然后我们前台进行razor模板的数据逻辑嵌套或html,css,js整个流程的开发. 缺点是:工作量是满大的,优点是,所有前端view层的东西都是可控的. 坑是比较多的, 比如数据出现问题时,没有一个经验丰富的前端或后端进行联调, 有问题短时间内是解决不了的. 一般跟后台合作分为这几种模式:1. 只产出html页面,然后交给后端来处理数据.这种的好处是工作量比较少,公司没

Web前端和后端的技术发展方向

今年web前端被炒得异常火热,但与此同时后端也是备受关注,这让很多web前端和后端的技术人员思考两者的发展方向,下面是小编收集的前端大牛的一些看法. 首先,兴趣是最重要的老师.个人认为除了少数意志力坚定的人,大多数人只有在自己有兴趣的领域才能发展事业. 但是是否"觉得兼容性很枯燥",就一定无法"感兴趣"下去, 这个其实不好一概而论.如果对兼容性问题感到麻烦棘手,这个恐怕很难做好前端.但是如果对探究某个兼容性问题有兴趣,但当探索完毕后,又厌烦每次都要为这个问题写额外的

对一个前端AngularJS,后端OData,ASP.NET Web API案例的理解

依然chsakell,他写了一篇前端AngularJS,后端OData,ASP.NET Web API的Demo,关于OData在ASP.NET Web API中的正删改查没有什么特别之处,但在前端调用API时,把各种调用使用$resouce封装在一个服务中的写法颇有借鉴意义. 文章:http://chsakell.com/2015/04/04/asp-net-web-api-feat-odata/源码:https://github.com/chsakell/odatawebapi 首先是领域模

前端加后端验证倒计时答题功能实现

思路 前端页面控制答题的开始,请求后台,后台记录开始的时间(发出请求的当前时间),再加上倒计时时间,得出结束时间. 后端返回给前端剩余的时间,前端通过Jquery实现倒计时的动态效果. 当倒计时结束,禁止答题,当用户刷新页面时,比较请求时间与结束时间,如果前者小于后者,答题继续,否则反之. 其中,答题时间.开始时间.结束时间,均保存在内存中. 实现(SpringMVC+Jquery) 后端: 1 /** 2 * Copyright 2016 Zhengbin's Studio. 3 * All