在一个应用程序中,我需要开始缓存数据,这让我开始思考……
现在问题出在缓存和可维护性上。
一方面,我在想,如果一切都是使用Javascript HTML模板构建的,那么我的应用程序将只提供一个HTML布局/shell和一堆JSON。如果你看看Facebook和Twitter的HTML源代码,这基本上就是他们正在做的事情(95%的json/javascript,5%的html)。这将使我的应用程序只需要缓存JSON (页面、操作和/或记录)。这意味着,无论您是访问JSON api的远程api开发人员,还是访问strait应用程序的远程api开发人员,都会访问缓存。也就是说,我不需要两个缓存,一个用于JSON,一个用于HTML。这似乎会将我的缓存存储减少一半,并使事情变得更简单。
另一方面,我认为,根据我所见/所见,在服务器端生成静态HTML,并进行缓存,似乎跨浏览器的性能要好得多;您可以立即获得图形,而不必等待javascript渲染它。StackOverflow似乎每件事都是用普通的超文本标记语言做的,谷歌也是如此,你可以看出……所有内容都会同时出现。请注意,尽管在twitter.com上,页面在0.5-1秒内是空白的,并且页面会分块: javascript必须呈现json。这样做的缺点是,对于任何动态的东西(如无休止的滚动,或网格),我无论如何都必须创建javascript模板。所以现在我有了服务器端的HAML模板、客户端的javascript模板,还有更多的东西需要缓存。
我的问题是,对于如何处理这个问题,有没有达成共识?你将两者混合在一起的经验与100%将一个放在另一个上的经验有什么好处和缺点?
更新:
我还没有决定使用100% javascript模板的一些原因是:
/#!/path
,但还不知道这将如何影响其他搜索引擎,以及较老的浏览器如何处理它。这似乎需要一个重要的设置。发布于 2011-03-07 03:40:07
永久私有数据存储。
您需要一个服务器来存储具有不同级别的公共/私有访问的数据。您还需要一台服务器来保护封闭源代码信息。你需要一个服务器来做一些你不想在客户机上做的繁重的事情。复杂的数据查询最好留给你的数据库引擎。索引和搜索尚未针对javascript进行优化。
此外,您还会遇到较旧的浏览器速度慢得多的问题。如果你没有运行FF4/Chrome或IE9,那么在客户端和服务器端的数据操作和页面构造之间会有很大的不同。
我自己将尝试建立一个web应用程序,完全使用MVC框架和模板,但仍然使用服务器连接到安全和优化的数据库。
但一般而言,应用程序确实可以完全用javascript和模板来构建。各种构造和javascript引擎已经足够先进,可以做到这一点。有足够多的流行框架可以做到这一点。纯javascript web应用程序不再是实验和原型。
哦,如果我们推荐的框架是这样的,那就看看backbone.js吧。
安全
让我们不要忘记,我们不信任客户端。我们需要服务器端验证。JavaScript是解释性的,是动态的,可以在运行时操作。我们从不信任客户的输入。
发布于 2011-03-07 03:44:43
我曾经将这两种方法混合在一起,但后来完全切换到客户端渲染,因为它真的很难正确地处理繁重的JavaScript。作为一个完整的解决方案,可以推荐JavaScriptMVC框架的方法。
它有一个名为EJS的视图渲染引擎,可以将你的视图压缩成普通的JavaScript,用于你的应用程序的生产构建。这使得它非常快(所有的超文本标记语言都预加载了单个压缩的JavaScript文件,因此一旦接收到模型的JSON数据,它就会被渲染)。我个人没有注意到EJS渲染和传输普通HTML之间的性能差异。
然后,对于您的API,遵循REST原则,缓存是关键约束之一。因此,如果您的应用程序正确支持JSON数据的HTTP缓存并使用压缩的客户端模板,您甚至可以看到性能的提高。
发布于 2011-03-07 04:26:25
我可能离得太远了,但是...
你看过CouchDB吗?(我和他们没有联系)我可能是错的,但你的情况听起来可能非常适合Apache CouchDB的使用我自己还没有真正用过它,但我不久前看过它,它是一个非常有趣的数据库。
它是一个基于文档的数据库,使用REST api进行连接(非常通用且易于使用)。它也非常以JSON为中心,速度非常快,占用空间很小;他们说它也可以驻留在手机和其他嵌入式应用中,但同时应该具有极强的可扩展性(也就是向上)。如果你是一个JS的大用户(你听起来像是这样),那么你可能对它很熟悉。
我只是在想,它可能会在许多方面派上用场,这里已经提出了许多方法,我想插一句,只是为了给您一个关于存储选项的想法:)
https://stackoverflow.com/questions/5212859
复制相似问题