保持稳定的protobuf api

恭喜！你已经达到了稳定的发布，或者也许你没有，而且客户已经决定依靠你的api.rather而不是从你的用户下面拉出地毯，你把它拿到了自己以让每个人都快乐。既然，您已经任务维护API兼容性，您需要一个指导灯来复制灵感。对于许多开发人员来说，条纹是API兼容性的圣杯：具有在十一十年前使用STRIFE API编写的付款系统的应用程序仍然在今天没有更改的功能。虽然我们应该渴望拥有可比的兼容性故事，而不是每个人都使用相同的技术堆栈。如果您使用GRPC / PROTOBUF而不是JSON / HTTP，那么在条纹级别的情况下维护API是什么样的？

在Authzed中，我们已经开始推动努力Protobuf API版本化。我们的最初目标是：

如果需要，在发货并释放新版本之前捕获打破更改

我们的起点是显而易见的：将我们现有的Ad-hoc protobuf设置迁移到Buf Toolchain.buf是一个新的，更快的protobuf编译器，但编译速度不是为什么我们正在切换：我们在其强大的功能上销售-放。

我们以前的工作流程是阅读protobuf文档以确定更改是否向后兼容.Castally，我们将在本地度过时间，只是为了确保改变是线兼容的。这是耗时和增加的要求我们开发人员团队的更多部落知识。

Buf消除了这种关注的疑虑，可以将可以内置为CI / CD工作流程的破坏性变化检测。前进，我们将能够发布官方版本控制和弃用策略，这可以通过BUF轻松而自信地强制执行。

即使我们在过去的Protobuf API工作，甚至在Google的内部Protobuf工具团队上工作的团队中甚至有一个Xoogler，我们仍然努力编写和维护惯用物体和服务定义.Buf具有大量索引Linting规则和预设，如谷歌和优步使用的规则。这些提示规则是从多年工程经验的高潮，并且是一个伟大的学习来源，从而借鉴文献包括常见规则和理由的描述适用。这些成语包括包命名，又描述了如何最好的版本您的包裹！

我们目前坚持我们发现的默认值。但是，在以下习语之间有一个很好的平衡，并为用户体验提供权衡;并非每个成语都很好地处理了每种语言中生成的代码。当我们最终遇到了选择忽略的特定规则时，Buf会使单行更改进行异常。

在BUF之前，我们有shell脚本，用于从Protobuf服务定义中生成代码.ECHEL脚本从项目变为项目，并且必须包含其他逻辑，如确定脚本相对于我们的.proto文件的位置。之后，我们可以重点关注将右标志传递给Protoc以生成代码。然而，这已经内置于Buf中，允许我们完全放弃我们的shell脚本。

现在我们有一个buf.gen.yaml，指定我们的插件和＃39; Arguments.by添加一个shebang到yaml文件的开头，我们甚至可以使您可以轻松地执行yaml文件以生成项目的代码：

＃！/ usr / bin / env -s buf generate ../protos --template版本：＆＃34; v1beta1＆＃34;插件： - 名称：＆＃34; Go＆＃34;出：＆＃34; pkg / proto＆＃34;选择：＆＃34;路径= source_relative＆＃34; - 名称：＆＃34; go-grpc＆＃34;出：＆＃34; pkg / proto＆＃34;选择：＆＃34;路径= source_relative＆＃34; - 名称：＆＃34;验证＆＃34;出：＆＃34; pkg / proto＆＃34;选择：＆＃34;路径= source_relative，lang = go＆＃34;

现在我们的DEV甚至不必学习如何使用BUF：我们的配置文件知道如何运行自己，并且CI / CD管道可以处理其余的。

这只是我们服务的API的开始。我们知道你永远无法真正逃避Hyrum的法律，但这些是我们最大限度地减少我们Make.Buf使我们能够通过验证我们API的第一步的第一步现在，我们可以专注于构建一个API指标，这些指标将用于数据驱动的决策，以便我们的弃用政策和API设计努力。我们对未来的BUF非常兴奋及其对Protobuf工具生态系统的影响。