项目之间共享的原型文件存储在哪里? [英] Where to store proto files which are shared among projects?

查看:69
本文介绍了项目之间共享的原型文件存储在哪里?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有项目A和项目B.它们可能使用不同的编程语言.项目A使用原型文件公开了一个API,项目B将使用该文件来以项目B使用的编程语言生成API.

I have project A and project B. They may be in different programming languages. Project A exposes an API using proto files, which project B will use to then generate the API in the programming language which project B uses.

但是原始文件存储在哪里?使用protobuf的常规方法是什么?您是否将从原始文件文件生成的文件添加到版本控制中?

But where are the proto files stored? What is the conventional way to do it with protobuf? Do you add the files generated from the proto files files to version control?

如果您在项目A和项目B中都存储了原始文件的副本,那么如果项目A更改了其API,则项目B将必须将它们复制过来.当有许多项目使用项目A公开的API时,这种方法就行不通了.

If you store a copy of the proto files in both project A and project B, then if project A changes its API, then project B will have to copy them over. This approach doesn't work great when there are many project using the API exposed by project A.

如果您有一个单独的项目C,其中包含共享的原型文件,则可以解决上述问题.但是,如何从项目A和项目B生成原始文件?

You can solve the above issue if you have a separate project, project C, containing the shared proto files. But then how do you generate the proto files from project A and project B?

推荐答案

我建议将 .proto 文件存储在单独的项目中.这些是您两个项目之间的合同,不一定由任何一个拥有".将它们存储在一个单独的项目中为两个项目成员协商文件更改提供了中立的基础-例如通过拉/合并请求过程,其中两个项目中的成员可能都充当审阅者.

I would suggest storing the .proto files in a separate project. These are the contract between your two projects, and they are not necessarily "owned" by either one. Storing them in a separate project provides neutral ground for both project members to negotiate changes to the files - for example through a pull/merge request process where there may be members from both projects acting as reviewers.

关于从原始文件生成代码,我可能会在需要它们的项目中这样做.因此,在您的情况下,项目C仅包含 .proto 文件,而项目A和B将拉入 .proto 文件并生成所需的代码.我感觉必须是这种方式,因为是项目A和B消耗了protobuf生成的代码.如果代码是在项目C中生成的,则项目A和B仍将必须拉出生成的代码才能使用它,并且由于项目C在技术上与A和B脱钩,因此不清楚需要使用哪种语言生成-全部?只是需要的两个?

As for generating code from the proto files, I would probably do this in the projects that need them. So in your case project C would only contain the .proto files, and projects A and B would pull the .proto files in and generate the code that they need. I feel like it has to be this way since it is projects A and B that are consuming the protobuf generated code. If the code was generated in project C then projects A and B would still have to pull the generated code to be able to use it, and since project C is technically decoupled from A and B it would not be obvious which languages would need to be generated - all of them? Just the 2 that are needed?

通过创建项目C,您正在创建一个可能容纳其他项目的 .proto 文件的场所.展望未来,您可能会拥有许多共享通用基本消息类型的项目.要管理具有许多互连项目的体系结构,尝试合并消息定义非常有意义,如果每个项目都维护自己的定义,这将是困难/不可能的,如果有重复的副​​本,则更糟(如您所说).将它们存储在一个位置中可以使新项目选择现有的定义并对其进行扩展(在进化准则之内),并且可以更严格地管理和维护一组定义,例如一组经验丰富的审阅者,确保从建模,命名空间或版本控制的角度来看,所有事情都是一致且明智的.

By creating project C you are creating a place that could potentially hold more .proto files for other projects. Thinking to the future you may have many projects that share common base message types. To manage an architecture with many interconnected projects it makes a lot of sense to try and consolidate message definitions, and this would be difficult / impossible if each project maintained it's own definitions, even worse (as you say) if there are duplicate copies. Storing them in one location allows for new projects to pick up existing definitions and expand them (within evolutionary guidelines), and allows for more rigor over managing and maintaining the set of definitions, e.g. a set of experienced reviewers making sure that everything is being done consistently and sensibly - be it from a modeling, namespacing or versioning perspective.

这篇关于项目之间共享的原型文件存储在哪里?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆