Versiona tus definiciones proto para asegurar la estabilidad.

¿Cómo estructurar archivos protobuf?

Dependiendo de los requisitos, la configuración de tus definiciones proto puede variar de una empresa a otra o de una aplicación a otra. El protocolo gRPC fue diseñado para utilizar buffers de protocolo o archivos .proto para implementar un esquema que puede generar un servidor y cliente que puedan enviar mensajes siguiendo los formatos definidos. Al principio, es posible que establezcas un archivo .proto en dos ubicaciones en dos repositorios o carpetas de GitHub diferentes que no compartan módulos comunes y tengas dificultades para conectar los bloques de lego. En algún momento, es posible que te encuentres con múltiples definiciones de servicios y mensajes que se duplican entre los repositorios. Con gRPC, puedes importar los módulos necesarios entre archivos para evitar la duplicación de código. Puede ser útil establecer un lugar central para configurar los archivos y enviarlos a los gestores de dependencias para ser consumidos en tu aplicación, como npm, cargo, o composer. Un ejemplo de esto se puede encontrar en esta ubicación y se puede probar con npm (el gestor de paquetes de Node) ejecutando npm i @a11ywatch/protos. Encontrarás los archivos de definición dentro de la carpeta node_modules.

Beneficios de versionar siguiendo semver.

Cuando sigues semver (control de versiones) con gRPC, te ayuda a definir una capa de compatibilidad que será verdadera en varios niveles. En general, gRPC no es disruptivo en las actualizaciones, excepto cuando haces lo siguiente.

Cambios disruptivos binarios

Los siguientes cambios no son disruptivos en el protocolo gRPC, pero el cliente debe actualizarse si actualiza el contrato de .proto o el constructor de cliente de gRPC más reciente. La compatibilidad binaria es importante si planeas publicar una biblioteca gRPC a través de un gestor de paquetes. Eliminación de un campo: los valores de un campo eliminado se deserializan en los campos desconocidos de un mensaje. Esto no es un cambio disruptivo en el protocolo gRPC, pero el cliente debe actualizarse si actualiza el contrato más reciente. Es importante que un número de campo eliminado no se reutilice accidentalmente en el futuro. Para asegurarte de que esto no suceda, especifica los números de campo y los nombres eliminados en el mensaje usando la palabra clave reservado de Protobuf. Cambio de nombre de un mensaje: los nombres de los mensajes no se envían normalmente a través de la red, por lo que este no es un cambio disruptivo en el protocolo gRPC. Sin embargo, el cliente debe actualizarse si actualiza el contrato más reciente. Una situación en la que los nombres de los mensajes se envían a través de la red es con campos Cualquiera, cuando se utiliza el nombre del mensaje para identificar el tipo de mensaje. Anidar o desanidar un mensaje: los tipos de mensaje pueden estar anidados. Anidar o desanidar un mensaje cambia el nombre del mensaje. Cambiar la forma en que se anida un tipo de mensaje tiene el mismo impacto en la compatibilidad que cambiar el nombre. Cambio de espacio de nombres: cambiar el espacio de nombres cambiará el espacio de nombres de los tipos de lenguaje generados. Esto no es un cambio disruptivo en el protocolo gRPC, pero el cliente debe actualizarse si actualiza el contrato más reciente.

Haciendo cosas geniales con nuestro sistema central de control de versiones.

Ahora que tenemos lo importante, podemos aprovechar las herramientas automatizadas que ayudan a mejorar los flujos de trabajo y la productividad de gRPC.

Referencias y recursos:

• Microsoft Versioning gRPC
• Definiciones de esquema
• gRPC