我正在开发一个 Yesod 应用程序，其中许多应用程序请求将导致从第 3 方 API 获取数据。获取的数据只会在后续请求中使用——也就是说，触发 API 标注的请求可以完成，而无需等待标注完成。
重要的是，给定的数据 xyz 不能被提取和存储两次，但应用的本质是多个客户端通常会对 xyz 感兴趣同一个时刻。如果我让每个应用程序线程查询数据库以查看是否已获取 xyz，即使规模不大，我也会开始看到与并发相关的问题。即使我要编写一堆代码来处理与并发相关的完整性问题(这并不有趣，而且很难确定我涵盖了所有情况)，以这种方式滥用昂贵的数据库查询也是不好的做法。
在我看来，一个不错的选择是让所有应用程序线程向 AMQP 队列发布请求(“确保已获取 xyz 数据”)，一个或多个“后台工作”类型的进程将订阅该队列。
在 this thread Greg Weber 建议采用双包布局，其中两个包都具有“我的持久层”作为依赖项。他提到我可以使用符号链接(symbolic link)或 hs-source-dir 来避免维护“持久层”代码的两个副本。
从高层次上来说，Greg 所描述的内容对我来说非常有意义，但我对 Haskell 还比较陌生，我担心我需要一段时间才能弄清楚细节。谁能给我更详细的介绍一下吗？
- 包目录应该如何布局？ (到底哪些文件构成了我的持久层？)
- .cabal 文件应该是什么样子？
- 一旦以这种方式布局，我是否需要更改我的(脚手架网站)源文件导入持久模型的方式？
另一部分是:您建议如何编写BackgroundJobs进程？除了 Yesod 的脚手架之外，我从未编写过生产 Haskell 代码。我大致了解了它——我只写一个main，在其中我将订阅消息队列，并根据每条消息进行调出/处理/存储——但是我需要担心例如手动 fork 以确保进程在等待标注完成时不会阻塞？
非常感谢。
最佳答案
我有一个应用程序，它由一个 Web 应用程序和一个单独的守护进程组成，该守护进程收集数据并将其插入与 Web 应用程序共享的数据库中。
我基本上将所有代码都放在同一个源代码树中，并且有两个定义 main::IO () 的文件，一个名为 webapp.hs ，另一个名为 webapp.hs称为daemon.hs。然后，我让 cabal 文件定义并构建两个单独的可执行文件。
不幸的是，我无法共享代码，因为它是我在日常工作中所做的内部项目。
关于haskell - 单独的 'App' 和 'BackgroundJobs' 包的布局，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/17220511/