跨多个Haskell软件包/微服务共享类型的最佳实践

Question

我在一个由多个微服务组成的Haskell项目中工作。多个服务同时需要某些类型，因此在单独的库中定义，这些库是根据需要导入的（每个类型都是版本化的）。但有些事情让我感到不舒服，我想知道哪个是关于这个话题的最佳做法。特别是：

• 我不知道如何处理共享类型的实例。为了避免孤立，必须在类型的模块中为每种类型定义实例。但是，所有导入软件包的微服务都不需要实例，无论如何都必须包含这些实例，可能会向微服务添加冗余依赖项。一个示例是由前端和后端共享的数据类型 T 。它有一个 Store 的实例，以便存储在前端不需要的数据库中，但仍然使前端依赖于商店包。
• 为了避免上一个问题，每次类型必须“离开”微服务以表示通过线路的类型时，我可以引入一个包装器。在前面的示例中，我将有一个可存储的T ，其中包含商店的实例。这给整个开发过程增加了很多开销。
• 分享类型或者每个微服务是否应该定义每种类型的表示是一个好主意，所以不必共享任何内容？因此，对于类型 T ，微服务 MA 将具有表示 AT 以及将其序列化以便将数据发送到微服务的实例< strong> B 会将数据解码为表示 MB.T 。

最后，关于此事的后勤方面，

• 构建项目最方便的方法是什么？ monorepo会比单独的repos / submodules更好吗？
• 也许与前一个相关，有没有办法在修改其中一个共享库时自动找出应该重新部署哪些微服务，因为库中的更改会影响微服务使用的一段代码？

Answer 1

我知道我在这里吐痰，但从那以后。

1. 项目 项目 项目
2. 您希望将实例与类型定义分开，仅作为分离关注点的机制，而不是将类型定义“打开”到整个地方定义的随机实例;
3. 您可能不打算将此作为通用库发布给其他人，因为某些不法分子会在您的某个类型上定义不兼容的Store实例;

那么假设您的孤儿实例 - 尽管是孤儿 - 可以合理地被视为为这些类型/类组合定义的全局唯一实例似乎是合理的。所以，如果有-fno-warn-orphans，那将是合理的使用。

您提到的避免孤儿的替代方案（newtype包装器和每个微服务类型定义）分别听起来很烦人且容易出错，以至于尽管存在不必要的依赖关系，但最好保持实例的类型。