En Python lo encuentro un poco engorroso de trabajar porque tienes que compilar los .proto(protoc) e importarlos como librería. A modo de spoiler, en Java se hace igual?, tengo curiosidad! Gracias! Abrazos
Sí, es muy parecido, rellenas el .proto y luego hay un paso en la build tool que genera las clases Java con métodos builder. Si además el .proto define un servicio RPC también se define una clase con los métodos para hacerles el override. Puede ser un poco engorroso por la parte que le toca (como es reactivo, no basta con hacer un return de un objeto, sino que hay que andar llamando a métodos), pero se adapta fácilmente.
Interesante, gracias. Te doy un poco mas de contexto también. Yo trabajo en la parte de Data, con Kafka para eventos transaccionales (los que se envían desde microservicios), y para deserializar el mensaje que viene en el evento, tengo que tener una librería con las últimas versiones de proto del mismo mensaje. Por otra parte los backenders tienen en cada repo sus .proto (aunque siempre tengo el registry para bajar la última versión del esquema). Dicho esto, imagínate la fiesta de crear la librería que se recompile cada vez que en un repo el .proto sufre cambios y el como se incluye dinámicamente los imports python para que se pueda deserializar (aparte tenemos .protos dependientes de otros protos)… Yo era feliz con JSON format como serde 😂 se lo chutabas al mensaje y a correr
La structs generados en Go son una maravilla son idiomaticos y simples de entender, no como la porq$#!ria de JavaScript :'v. Una vez me mandaron a hacer un cliente grpc en javascript que hiciera una peticion a un servidor grpc y despues redireccionar esa data a un frontend, y la documentacion del paquete que genera el codigo a partir del .proto en js es muy pobre, al final si le entendi pero tarde como 3 dias en entenderlo xd
El mejor resumen que he visto para comenzar con grpc muchas gracias compa
Usar gRPC es una muy buena solución del eterno problema que tienen los equipos de FE y BE poniéndose de acuerdo y respetando los contratos de datos.
En Python lo encuentro un poco engorroso de trabajar porque tienes que compilar los .proto(protoc) e importarlos como librería.
A modo de spoiler, en Java se hace igual?, tengo curiosidad! Gracias!
Abrazos
Sí, es muy parecido, rellenas el .proto y luego hay un paso en la build tool que genera las clases Java con métodos builder. Si además el .proto define un servicio RPC también se define una clase con los métodos para hacerles el override. Puede ser un poco engorroso por la parte que le toca (como es reactivo, no basta con hacer un return de un objeto, sino que hay que andar llamando a métodos), pero se adapta fácilmente.
Interesante, gracias. Te doy un poco mas de contexto también. Yo trabajo en la parte de Data, con Kafka para eventos transaccionales (los que se envían desde microservicios), y para deserializar el mensaje que viene en el evento, tengo que tener una librería con las últimas versiones de proto del mismo mensaje.
Por otra parte los backenders tienen en cada repo sus .proto (aunque siempre tengo el registry para bajar la última versión del esquema).
Dicho esto, imagínate la fiesta de crear la librería que se recompile cada vez que en un repo el .proto sufre cambios y el como se incluye dinámicamente los imports python para que se pueda deserializar (aparte tenemos .protos dependientes de otros protos)…
Yo era feliz con JSON format como serde 😂 se lo chutabas al mensaje y a correr
+1
La structs generados en Go son una maravilla son idiomaticos y simples de entender, no como la porq$#!ria de JavaScript :'v.
Una vez me mandaron a hacer un cliente grpc en javascript que hiciera una peticion a un servidor grpc y despues redireccionar esa data a un frontend, y la documentacion del paquete que genera el codigo a partir del .proto en js es muy pobre, al final si le entendi pero tarde como 3 dias en entenderlo xd