用户可以在我的应用程序中创建PDF，这需要花费一些时间才能生成，因此必须在后台作业中完成。没问题，但是会有延迟，必须通知用户PDF已准备就绪。
因此，第一选择是在应用程序本身中发送带有下载链接或推送通知的电子邮件。我的首选是推送通知，所以我猜想ActionCable是可行的方式吗？我的应用程序在Heroku上运行，那么ActionCable还是一个不错的选择，还是另一个解决方案更可取？
那么还有另一个考虑，在用户下载之前，将生成的PDF存储在哪里？我可以使用ActiveStorage将其上传到Azure / S3 / etc，也可以将其临时存储在应用程序文件夹中，下载后将其删除。我更喜欢最后一遍，因为PDF仅存在几分钟，因此真的不需要将其存储在云中吗？
答案 0 :(得分：1)
您在这里有一个非常广泛的问题，它很大程度上取决于总体用户需求和您希望他们拥有的经验。
在临时存储PDF方面，我将从最简单的部分开始。这里有几件事要牢记。
我想说，从可伸缩性和应用程序安全性的角度来看，将PDF存储到云是必经之路。在应用程序服务器上打开可写目录会带来风险。另外，如果您需要扩展到多个服务器，则将无法使用。使用适当的API，从云存储中删除项目并不难。
以某种方式对用户进行身份验证以下载PDF是否必不可少？如果将PDF推送到云存储桶中，这将更具挑战性（除非您使用非常复杂且难以猜测的名称来命名PDF，该名称只能通过经过身份验证的应用程序访问）。如果数据不太敏感，那么您的电子邮件通知可以直接显示链接，但是您将不容易知道用户是否已检索PDF，现在可以将其删除。
在通知方面，出于某些原因，我会选择使用电子邮件。简单是主要因素。您有使用ActionCable的经验吗？从表面上看，它看起来很简单，但是在使用它时，要记住很多事情：基础架构和UI是主要的。另外，从用户体验的角度来看，用户是否可能会在应用程序中闲逛以等待PDF完成？如果他们注销该怎么办？他们怎么知道PDF可用？
如果生成PDF的时间尺度很短，并且绝对没有优化可伸缩性，那么您可以考虑采用一种更简单的机制来检查每个用户操作的用户通知（例如，对user_notifications表的简单查询），并使用UI可以检查并用于异步检索通知的Flash或其他会话标志。
只是想法。不可能给出明确的答案。