我将我的主应用程序和管理员应用程序构建为微服务，他们通过api进行通信。我想在这两个应用程序之间分享一些常量。
例如，我有可以拥有角色所有者或常规的用户模型。在管理员应用程序中，我可以搜索用户，在此搜索中，我有下载硬编码用户类型（所有者，常规）。这没关系，但是当我更改命名（例如Regular - ＆gt; Standard）时，我也必须更新我的管理员应用程序。
为了避免在我每次更改主应用程序中的某些核心命名时更改管理员应用程序，我想以某种方式共享这些常量，因此主应用程序中的每个更改都会同时更改管理员。
目前我找到了两个有利有弊的解决方案：
首先是通过json api将常量从主应用程序发送到admin。我已经构建了一个类，它将在类变量中获取并存储所有常量，因此它可以从应用程序的每个部分获得。这个解决方案的好处是性能（感谢memoization它只有一个api请求），以后很容易使用。不好的是我不知道在这种情况下如何处理测试。当然我不能让我的测试向主应用程序发出请求并且对此请求进行存根使得整个想法毫无意义，因为在主应用程序中每次更改常量后我都需要在管理应用程序中更改测试。
我想到的第二种方法是构建一个存储所有常量的gem。它实现起来非常简单，但这意味着每次我想在主应用程序中更改常量时，我都需要对此repo进行更改。我也和大团队合作，他们不会同意他们必须同时处理2个回购。
您如何看待这些解决方案？除了测试之外，第一个似乎对我来说是完美的，所以也许你有一些想法如何在没有实际值的情况下存根这些常量？我还没有尝试过宝石解决方案，所以如果你看到一些障碍请告诉我。 也许这个问题还有另一个更好的解决方案吗？
答案 0 :(得分：1)
我不确定在服务本身的结构方面是否有更好的解决方案，例如，两个服务中的一个可以有一个API，它返回另一个使用的常量。
但要回答这个问题，你可以使用一个引擎，或者更有可能简单地共享常量，一个宝石。您可以使用bundle gem <GEM NAME>创建一个新的gem，然后将其添加到两个应用程序的Gemfile中。
您需要拥有一台宝石服务器（例如geminabox）或直接指向您的代码仓库，例如
gem 'my-gem', git: 'git@my-server.com:git/my-gem`
就个人而言，我会使用返回常量的API，因为你可能想用另一种语言重写一个服务，在这种情况下共享一个gem会崩溃。
答案 1 :(得分：0)