【问题标题】:Chunk and pipe big amounts of data for client-site (browser) PDF generation为客户端(浏览器)PDF 生成分块和管道大量数据
【发布时间】:2016-03-04 03:47:51
【问题描述】:

我正在尝试从网络服务器 (Node.js) 下载 HTML/JSON 数据并在客户端将其转换为 PDF。我希望在用户的浏览器上进行处理,这样我的服务器就不会因 pdfs 转换而过载。

如果数据不是那么大,应该不是问题。一份报告(从服务器下载的数据)可以总计 200、300MB,浏览器无法处理内存中的这么多数据。正因为如此,我(可能)需要以块的形式下载并保存数据,或者将其直接通过管道传输到 PDF 转换器。

但我无法理解它。如何切片和存储/管道下载的数据?我一直在环顾四周,发现了几个图书馆,但我仍然不知道如何让它们一起工作。有什么想法吗?

【问题讨论】:

  • 应该发送到浏览器的所需数据大小是多少?
  • 从 50Kb 到 800MB、900MB。
  • 您不能使用分块响应或 websocket 将分块数据传输到客户端吗?不过,客户端上的分段 pdf 生成仍然具有挑战性。
  • 是的,@lipp,这正是问题所在……如何在不将其存储在内存中的情况下生成 pdf。
  • 你检查过jsPDF,它是一个客户端pdf生成器,如果他们有解决此类问题的方法,我不会感到惊讶,也许你可以用它来获得灵感.

标签: javascript pdf download stream pipe


【解决方案1】:

我认为让应用消费者在他们的计算机上生成 800MB 的 pdf 文件不是一个好主意。

如果记录较大,我会避免使用 JSON。如果实际记录数据超过 25 MB,我会以二进制/压缩形式发送该数据。

至于查看所有这些数据,我什至不认为 PDF 是要走的路。我会为最终消费者创建一个特殊的离线查看器。也许是自定义浏览器插件或扩展程序,这样他们在查看报告时就不必在内存中投入 800MB。

另一个考虑因素可能是使用 Google Drive 或 Rackspace OpenCloud 或 AWS 或类似性质的东西,原因是,如果在传输过程中消费者端出现问题,您的服务器也必须重新启动。如果您将它放在 CDN 后面的云中,那么他们可以根据需要从靠近他们的服务器下载它多次。此外,您的服务器应该能够以比将其发送到客户端更快的速度将其发送到云端,这样您的服务器将资源绑定打开的时间就会更少。

【讨论】:

  • 有趣的观点。你能告诉我更多为什么你认为在客户端生成pdf是一个坏主意吗?我在想将处理成本推给用户会更好,这样我的服务器就不会被多个处理请求淹没——而且我不需要更大的服务器。它降低了应用程序的总体成本。至于 PDF 是不是最好的格式,很遗憾,这不是一个选项,而是业务需求。
  • 我同意将尽可能多的工作委派给客户是最好的。我有一种感觉,我会强烈反对这一要求,因为我倾向于怀疑这对最终消费者来说是否是最好的体验。但为了确定最佳解决方案,我需要确切地知道原始数据是什么以及消费者应该从原始数据中获得哪些信息。例如,我建立了一个风电场管理系统。原始数据是刀片损坏/维修细节。客户获得包含图表和详细信息的 PDF 报告,但报告仅限于一个项目检查/维修。
猜你喜欢
  • 2011-09-09
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2019-10-05
  • 1970-01-01
  • 2019-08-17
  • 2017-03-11
  • 2016-04-10
相关资源
最近更新 更多