【问题标题】:Using Breeze.js with server-side caching将 Breeze.js 与服务器端缓存一起使用
【发布时间】:2014-09-19 07:09:12
【问题描述】:

我一直在阅读和使用 Breeze.js,它看起来真的很棒,但我有一个问题:服务器端缓存。

我可以理解在客户端缓存实体的优势,但对于高流量网站来说,这似乎还不够。

如果我有一个 Companies 表并且我的应用正在缓存该客户端,这一切都很好,但如果我有 10,000 名用户第一次同时访问我的网站,那么我的数据库仍然有 10,000 次点击,因为如果我将它缓存在服务器上,则反对为第一个用户调用单个数据库。

据我所知,Breeze 仅在您像这样直接访问数据库时才真正起作用。我可以想象在我的数据库和处理缓存的 Breeze 客户端之间有一个 OData 服务,但我想这会在我的代码中涉及大量额外的基础设施,特别是在将元数据发送给客户端方面。

我认为 Breeze.js 在默认情况下不能很好地与服务器端缓存配合使用是不是错了?

【问题讨论】:

    标签: javascript caching breeze


    【解决方案1】:

    好消息是服务器端缓存是一个不错的选择。请记住,Breeze 是一种客户端技术,适用于任何使用 HTTP 和 JSON 的资源。它不一定是数据库。

    元数据根本不是问题。我们的元数据文档描述了几种将元数据视为静态资源的技术。例如,您可以轻松地将其 JSON 化为 JavaScript 文件并将其导入客户端;将该 JavaScript 文件放在您的 CDN 上。

    这是您的服务器 API。在 Redis 中缓存某些高使用、低容量的集合(例如,那些填充下拉框的讨厌的参考值)将是小菜一碟。

    与任何服务器端缓存策略一样,您必须计划要缓存哪些集合、缓存未命中后去哪里以及如何处理更新。

    我希望我有时间起草一个样本。也许你会试一试并与我们分享。

    【讨论】:

    • 我实际上从未研究过 Redis。我得试一试。我想我对元数据的关注是它的生成机制。目前我没有缓存生成元数据的方法,但现在我考虑一下,考虑到我的后端架构,通过管道传输数据应该是微不足道的。我会研究你的建议。谢谢。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2013-07-31
    • 2017-09-17
    • 2013-05-26
    • 2019-12-08
    • 2018-03-14
    相关资源
    最近更新 更多