使用服务器端页面呈现可带来哪些优势?


19

我正在开发一个Web应用程序,目前我已经用html / js / css编写了整个网站,而在后端,我有servlet承载一些RESTFUL服务。所有表示逻辑都是通过获取json对象并通过javascript修改视图来完成的。

该应用程序本质上是一个搜索引擎,但是它将具有不同角色的用户帐户。

我一直在研究Play和Spring等框架。我是Web开发的新手,所以我想知道使用服务器端页面呈现会带来哪些优势?

是:速度吗?更轻松的开发和工作流程?访问现有图书馆?更多?上述所有的?


4
安全是一大问题。特别是当应用程序是动态的并且需要与数据库通信时。
Oded 2012年

2
@Oded-与在API中相比,为什么在呈现页面时更容易实现安全性?我一直认为,无论哪种方式,您都必须编写程序,但是从心理上记住(在我看来)在执行API时不信任客户端会更容易。我问是因为我是否忽略了我真正想知道的东西。
psr 2012年

1
@psr他所指的数据安全性不如用户安全性(例如MITM漏洞利用)。只是一个猜测而已。
maple_shaft

1
@psr-同意。但是,就在昨天,我回答了一个问题,其中OP在JS中嵌入了连接字符串...
Oded 2012年

1
@maple_shaft-需要考虑的是MITM,但我不确定为什么它会对API与服务器生成的HTML有所不同。我认为API相对更易于编程,因此在某种程度上来说更容易破解,但是我怀疑那是您的意思。
psr 2012年

Answers:


16

服务器端HTML呈现:

  • 最快的浏览器渲染
  • 页面缓存可以快速而有效地提高性能
  • 对于“标准”应用程序,许多UI功能是预先构建的
  • 有时被认为更稳定,因为组件通常需要进行编译时验证
  • 依靠后端专业知识
  • 有时开发速度更快*

*当UI要求非常适合框架时。


客户端HTML呈现:

  • 较低的带宽使用
  • 较慢的初始页面渲染。在现代桌面浏览器中甚至可能不会引起注意。如果您需要支持IE6-7或许多移动浏览器(移动Webkit不错),则可能会遇到瓶颈。
  • 首先构建API意味着客户端可以轻松地成为专有应用,瘦客户端,另一个Web服务等。
  • 依靠JS专业知识
  • 有时开发速度更快**

**当用户界面很大程度上是自定义的时,会有更多有趣的交互。另外,我发现在浏览器中使用解释代码的编码明显比等待编译和服务器重新启动要快。


您可能还会考虑使用前端/后端模板系统(例如mustache)的轻量级后端实现的混合模型。


1
哇,完全忘记了缓存机会!
Michael K

“对于“标准”应用程序,许多UI功能是预先构建的”,这是不相关的,服务器和客户端都具有。
雷诺斯2012年

@Raynos他没有提到使用客户端框架,但是如果他使用的是客户端框架,那是个好主意。
peteorpeter 2012年

1
谢谢,这主要是我想要的答案。我没有对客户端框架做太多的工作,但是我根据LinkedIn的选择对ust.js进行了一些研究。我知道胡须是一种替代选择,但我会做更多研究。我可能会进行某种混合,主要是我想将其推送到服务器端,以提高性能。再次感谢。
user1303881'4

我不会真正将列出用于“客户端HTML呈现”的任何内容作为优势。“有时开发速度更快”比考虑最前沿的浏览器(IE 8等)更能飞出窗口。
null

3

服务器端HTML生成:

  • 更容易调试;
  • 浏览器兼容性没有问题;
  • 使用经典的全页服务器端生成,即使HTML包含大量不变的部分,也很难缓存HTML。(解决方案是通过AJAX调用获取HTML片段);
  • 不利用动态HTML的缓存代理和CDN;

客户端HTML生成:

  • 难以调试;
  • 过时的浏览器存在一些问题;
  • 缓存HTML模板客户端无问题;
  • 对HTML模板和JS代码利用缓存代理和CDN;
  • 更低的网络使用率;

请注意,在成功的移动网站的情况下,客户端生成是完成此操作的方式,显然,现代浏览器(基于WebKit的浏览器在移动市场中约占70-80%)的效率更高。

LinkedIn上有一篇文章以ustry.js为例介绍了客户端方法的优势:“将JSP抛在脑后:将LinkedIn迁移到ustust.js客户端模板”


1
+1在现代智能手机(主要使用webkit mobile)上,JS不太可能成为瓶颈,而单元网络带宽
peteorpeter 2012年

1

这取决于您的要求。如果您需要一个高性能,低延迟的解决方案,该解决方案取决于许多小任务,则可以采用与您描述的结构类似的结构。但是,在Java,PHP和C#中,最常见的解决方案并不是默认设置。

大多数Web应用程序都非常依赖数据库-它们中的大多数是如此之多,以致页面至少要经过一个调用就无法呈现。显然,由于以下几个原因,您不想公开公开数据库:

  • 安全性(如Oded所述)-您绝对不会希望公开暴露你的网络!理想情况下,从外部到您的系统的唯一接口应该是https到您的服务器。
  • 易于开发-您真的,真的真的不希望用Javascript编写SQL,并且为Web演示而设计的语言在RDB中不能很好地工作。例如,它们没有状态的概念。

因此,当您需要数据库时,可以使用与Java,C#,PHP等类似的语言。它们的最简单生成方法如下:使用模板语言(最著名的是PHP,但JSP和ASP是另外两种非常通用的语言)来构造页面。该语言提供了调用其他模块的构造。在PHP中,通常使用MVC模式在页面或另一个PHP文件中。在JSP中,您可以使用scriptlet或JSP表达式语言。这些其他模块可能需要繁重的工作来连接到数据库,执行逻辑并将值返回到您的视图层。最终结果是生成的HTML页面,呈现在服务器上并发送给客户端。

当数据库与页面渲染器位于同一网络上时,您还将获得更好的性能。客户端只需要执行一个请求就可以接收一个页面-您可能需要执行10-15个DB请求,才能获得用户所需的所有信息。如果客户端必须全部完成,那么网络上的毫秒级延迟将为数秒至数分钟。

当系统变得更大时,关注点和核心能力的分离变得至关重要。HTML非常适合显示。Javascript适合动态内容。SQL非常适合查询数据库,而其他语言则擅长业务逻辑。作为开发人员,我们的工作是使用所有可用的工具来构建可维护的系统。易于开发是一个良好系统的重要组成部分。在我看来,它几乎与性能和可用性一样重要。伟大的系统会随着时间而发展。糟糕的系统从一开始就编写得很糟糕,并且从未得到改进。


you can't write SQL in Javascript 真?!您是否曾经看过 Java的StackOverflow问题?不幸的是,我希望与众不同。当然,这是您可能在客户端代码中可能做的最糟糕的事情,但是...
maple_shaft

...我也忘记了Node.JS,但是那就是服务器JS,它是完全不同的动物。
maple_shaft

显然您可以-TIL!只是...哇。但是,请谈论滥用该语言!
Michael K

2
REST接口是客户端当前如何通过json对象访问数据库数据的方式。它不会公开所有内容,并且此应用程序是私有企业网络的一部分。接口的优势之一是企业中其他应用程序可以利用他们想要的任何服务。从开发的角度来看,我可以让前端开发人员在html / js / css中随心所欲地进行操作,然后他们就可以仅通过Java开发人员设计的RESTful接口进行访问。但是,我们大多数人都有综合的技能,因此可能不需要划分。
user1303881'4

3
-1:@MichaelK:您正在与您想象中的稻草人讨论,但与现实生活完全无关。RESTful确实使用HTTP。没人需要用JS编写SQL,这就是RESTful接口的目的。同样,RESTful并不意味着,数据库查询存在一对一的映射。您的答案可能在1990年代有效,但现在在2012年。
vartec'4

0

移动客户端通常受功率,带宽和内存限制。最好在服务器上为它们呈现页面。

对于桌面客户端,您可以考虑发送js + json以在客户端上呈现页面,使其动态可更新等。


然而,实际上,恰恰相反。实际上,jQuery Mobile项目完全基于客户端渲染的思想。
Pointy '04

@Pointy:是的,这可能是相反的。应该测试特定页面在特定客户端上的行为。提供指向替代项的链接(例如“移动”和“桌面”版本链接)也可能对用户有所帮助。
9000

如今的移动设备具有更多的特点是高延迟而不是低带宽或低处理能力。在我最近从事的项目中,我们更关注页面大小而不是渲染速度-现代手机非常不错。
Michael K

@Pointy jQuery Mobile项目也是一大堆不应该使用的可怕代码。人气!==价值
Raynos 2012年

@Raynos我们实际上正在使用Jquery Mobile,也取得了很好的成功。你知道我们不知道的事吗?;)
Michael K

0

服务器端渲染的一个巨大优势是可访问性-基于javascript的应用程序对于视力不佳的人仍然是一个大问题。那就是您可能想要迎合的一个叫做“ googlebot”的盲人。他的JavaScript也不太好。


好一点,尽管此应用程序因为是私有的而不需要SEO,但我也在开发一些个人应用程序,这是该领域的考虑因素。
user1303881 2012年

:Googlebot完全解释JS / AJAX相当长的一段时间searchenginewatch.com/article/2122137/...
vartec

@vartec:我认为该文章中的主要观点是“现在可以阅读和理解通过AJAX和JavaScript实现的某些动态注释”。我的怀疑是它涵盖了Disqus和Facebook,但没有涵盖您的自定义Ajax设置。
Wyatt Barnett
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.