gpt4 book ai didi

json - 使用版本控制在项目之间共享 Json Schema 文件

转载 作者:行者123 更新时间:2023-12-03 16:38:50 26 4
gpt4 key购买 nike

问题

我们有一些独立的项目(微服务),在他们生命中的某个时刻会引用一些 JSON 模式文件,不用说每个项目都有自己的编程堆栈(尽管主要是 Nodejs 和 Golang)。

在保持版本控制的同时在不同项目之间共享此类数据的最佳实践是什么?

下面我描述了我自己的解决方案,但我也希望得到您的反馈。

我的解决方案

  • 我已经建立了一个 github 项目并将 json 模式文件放在那里
  • 对于模式的每次更改,我都会更新 repo 并用新版本标记它
  • 我用 jsdelivr像这样访问它:https://cdn.jsdelivr.net/gh/[GITHUB-ID]/[GITHUB-PROJECT]@[TAG]/schema.js
  • 当我想克隆需要模式文件的随机微服务的代码时,作为构建过程的一部分,我从 下载模式文件jsdelivr 并将其保存到我的本地仓库,但是下载的模式文件被 git 忽略。

  • 你怎么看,有没有更好更顺畅的方式来处理这个案子?

    最佳答案

    处理多个依赖项是(至少在我看来),这是使用多个微服务的主要痛点之一。我能想到或见过的几种方法是——

  • 拥有 Monorepo -

    如果您将所有服务都放在一个存储库下,这将变得容易得多。这意味着您可以使用像 lerna (用于 JS 项目)或类似的 monorepo 助手。在这种情况下,您可以有一个文件夹结构,如 -

  • -- root
    ---- shared schema files ( with versioning )
    ---- service 1
    ---- service 2


  • 拥有提供模式文件的服务 -

    这里的想法是为架构文件提供单独的存储库,并在您的任何应用程序加载时提供它们。这可以通过多种方式完成 -

    一种)。通过为不同的语言维护不同的包——比如用于 ruby​​ 的 gems 和用于 Node 项目的 node_modules。然后这些模块负责从中央仓库获取相关模式。

    乙)。通过在本地运行 docker 镜像 - 您还可以将这些模式保留为 docker 镜像(当然带有版本控制)并通过挂载为逻辑卷来服务它们。图像可以包含维护模式所需的各种帮助库(可能是验证器、测试和模式的 UI View )。

  • PS:您可能还想看看 prototool 之类的工具.

    关于json - 使用版本控制在项目之间共享 Json Schema 文件,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/56205986/

    26 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com