Definir un servicio gRPC en Go empieza por modificar el archivo .proto y dejar que Protocol Buffers genere el código por ti. Aquí aprendes a crear el StudentService con dos métodos unarios listos para implementar, ideal si estás construyendo APIs eficientes con Go y gRPC.

Qué dependencia necesitas para trabajar con Protocol Buffers en Go

Antes de tocar el archivo .proto, instala el paquete oficial que permite a Go manejar los proto buffers en tiempo de ejecución.

En la terminal corres este comando [0:25]:

bash go get google.golang.org/protobuf

Con esa dependencia tu proyecto ya entiende cómo serializar y deserializar los mensajes que vas a definir. Es el cimiento sobre el que se apoya todo lo demás.

¿Qué es un proto buffer? Es el formato binario que usa gRPC para enviar datos entre cliente y servidor. Lo defines una vez en un archivo .proto y se traduce a código en el lenguaje que necesites.

Cómo se definen los mensajes GetStudentRequest y SetStudentResponse

Los mensajes son las estructuras que viajan entre cliente y servidor. Para el servicio student necesitas dos nuevos dentro de tu student.proto [0:42].

El primero es GetStudentRequest, que lleva un único campo de tipo string llamado id en la posición 1. Esa posición no es un valor, es la etiqueta que usa el proto buffer para identificar el campo en el binario.

El segundo es SetStudentResponse, que también incluye un id como respuesta tras crear o registrar un estudiante.

proto message GetStudentRequest { string id = 1; }

message SetStudentResponse { string id = 1; }

Fíjate en el detalle: el número junto al campo no es el valor que vas a enviar, es la posición dentro del mensaje. Esa convención permite que proto buffers sea retrocompatible cuando agregas nuevos campos.

Cómo creas el StudentService con métodos RPC unarios

Hasta este punto solo tenías mensajes flotando, pero no un servicio que los conecte. El servicio se declara con la palabra clave service y agrupa los métodos disponibles [1:25].

Qué métodos vive dentro de StudentService

Dentro de StudentService defines dos llamadas unarias, es decir, una petición y una respuesta sin streaming.

• GetStudent: recibe un GetStudentRequest y devuelve un Student.
• SetStudent: recibe un Student y devuelve un SetStudentResponse.

proto service StudentService { rpc GetStudent(GetStudentRequest) returns (Student); rpc SetStudent(Student) returns (SetStudentResponse); }

Los dos son RPC unarios porque mandan un solo mensaje y reciben uno solo de vuelta. Más adelante vas a sumar streaming de cliente, de servidor y bidireccional, pero la base unaria es la que conviene dominar primero.

¿Qué es un RPC unario? Es una llamada remota donde el cliente envía un mensaje y el servidor responde con otro mensaje. Sin flujos, sin secuencias: una pregunta, una respuesta.

Qué archivos genera el compilador de Protocol Buffers

Una vez modificado el .proto, vuelves a correr el comando de compilación que ya tenías a mano. Te conviene guardarlo cerca porque lo vas a usar muchas veces durante el proyecto [2:15].

Al ejecutarlo notas algo nuevo: ahora se generan dos archivos en lugar de uno.

1. El archivo original donde viven todos los mensajes que definiste.
2. Un archivo adicional específico de gRPC, con los clientes y servidores listos para usar.

Ese segundo archivo aparece justo porque acabas de declarar un servicio con métodos. Antes no existía porque solo tenías mensajes sueltos. Toda la plomería del cliente y del servidor se escribe sola a partir de tu definición.

¿Por qué se generan dos archivos al compilar el proto? Porque uno contiene los mensajes serializables y el otro contiene el código gRPC del cliente y servidor. gRPC solo aparece cuando defines un service en el .proto.

Esa es la ventaja real de Protocol Buffers: defines el contrato una vez y obtienes código consistente, tipado y mantenible sin escribirlo a mano. Con el contrato listo, lo siguiente es darle vida a GetStudent y SetStudent en el servidor.

¿Cómo crees que vas a estructurar la implementación de estos métodos? Cuéntame en los comentarios qué patrón sueles usar cuando arrancas un servicio gRPC desde cero.