gRPC es un framework de RPC (Remote Procedure Call) de alto rendimiento que utiliza Protocol Buffers (Protobuf) como su lenguaje de definición de interfaz (IDL). A diferencia de REST, donde el contrato suele ser una documentación secundaria (como OpenAPI/Swagger), en gRPC el contrato es el punto de partida absoluto: defines tus mensajes y servicios en un archivo .proto y el código para los clientes y servidores se genera automáticamente para tu lenguaje preferido.
Esto funciona de forma tan eficiente porque Protobuf es un formato de serialización binario, no de texto. Mientras que JSON debe transmitir los nombres de las claves (ej. "user_id": 123) en cada mensaje, Protobuf solo envía el número de campo asignado y el valor, lo que reduce drásticamente el tamaño del payload y el uso de CPU al evitar el parsing de strings complejos. gRPC aprovecha esta eficiencia sobre HTTP/2, permitiendo multiplexación (múltiples peticiones sobre una misma conexión TCP) y streaming bidireccional nativo.
Debes elegir gRPC cuando construyes la comunicación interna entre tus microservicios (tráfico east-west), donde la latencia es crítica y el throughput es alto. También es la opción ideal si tienes un ecosistema políglota donde necesitas que un servicio en Go se comunique con uno en Rust o Python con tipos estrictos garantizados. Si estás construyendo una API pública para que la consuman desde navegadores o clientes web de forma directa, REST/JSON sigue siendo la opción lógica por su compatibilidad universal y facilidad de depuración con herramientas simples.
Si ignoras la gestión de la evolución del esquema (como reutilizar números de campo de Protobuf) o si no propagas correctamente el context.Context en el servidor, terminarás con errores de deserialización crípticos o fugas de goroutines en el servidor cuando el cliente cancele una petición.
// Nota: Para ejecutar esto en un entorno real, primero necesitas definir el .proto
// y generar el código con `buf generate`. Aquí simulamos la estructura lógica.
/*
syntax = "proto3";
package order;
option go_package = "example.com/order";
service OrderService {
rpc GetOrder(OrderRequest) returns (OrderResponse);
rpc StreamOrders(OrderRequest) returns (stream OrderResponse);
}
message OrderRequest {
string order_id = 1;
}
message OrderResponse {
string order_id = 1;
string status = 2;
int32 amount_cents = 3;
}
*/
package main
import (
"context"
"fmt"
"log"
"net"
"time"
"google.golang.org/grpc"
"google.golang.org/grpc/codes"
"google.golang.org/grpc/status"
// Estos serían los paquetes generados por buf:
// "example.com/order/orderpb"
)
// Mock de la interfaz generada para que el ejemplo sea ejecutable
type OrderRequest struct{ OrderId string }
type OrderResponse struct {
OrderId string
Status string
AmountCents int32
}
type OrderServiceServer interface {
GetOrder(context.Context, *OrderRequest) (*OrderResponse, error)
StreamOrders( *OrderRequest, func(*OrderResponse) error) error
}
// --- Implementación del Servidor ---
type server struct {
// En un caso real, aquí inyectarías la base de datos
}
func (s *server) GetOrder(ctx context.Context, req *OrderRequest) (*OrderResponse, error) {
// Simulamos una validación de negocio
if req.OrderId == "" {
return nil, status.Error(codes.InvalidArgument, "el ID de orden es requerido")
}
// Verificamos si el cliente canceló la petición (importante para evitar work desperdiciado)
select {
case <-time.After(50 * time.Millisecond):
return &OrderResponse{
OrderId: req.OrderId,
Status: "PROCESADO",
AmountCents: 1500,
}, nil
case <-ctx.Done():
return nil, ctx.Err()
}
}
func (s *server) StreamOrders(req *OrderRequest, send func(*OrderResponse) error) error {
for i := 0; i < 3; i++ {
err := send(&OrderResponse{
OrderId: req.OrderId,
Status: fmt.Sprintf("ESTADO_%d", i),
AmountCents: int32(100 * i),
})
if err != nil {
return err
}
time.Sleep(100 * time.Millisecond)
}
return nil
}
// Interceptor: Middleware para observar llamadas (observabilidad/logging)
func unaryLoggingInterceptor(
ctx context.Context,
req interface{},
info *grpc.UnaryServerInfo,
handler grpc.UnaryHandler,
) (interface{}, error) {
start := time.Now()
resp, err := handler(ctx, req)
log.Printf("Método: %s | Duración: %s | Error: %v", info.FullMethod, time.Since(start), err)
return resp, err
}
func main() {
// 1. Setup del servidor
lis, err := net.Listen("tcp", ":50051")
if err != nil {
log.Fatalf("Fallo al escuchar: %v", err)
}
// Usamos un interceptor para logging, algo esencial en producción
s := grpc.NewServer(
grpc.UnaryInterceptor(unaryLoggingInterceptor),
)
// En un caso real: orderpb.RegisterOrderServiceServer(s, &server{})
// Como no tenemos el código generado, simulamos que el servidor está corriendo.
fmt.Println("Servidor gRPC escuchando en :50051...")
// Lanzamos el servidor en una goroutine
go func() {
if err := s.Serve(lis); err != nil {
log.Fatalf("Error en el servidor: %v", err)
}
}()
// 2. Setup del cliente (simulado)
time.Sleep(time.Second) // Esperar a que el servidor levante
conn, err := grpc.Dial("localhost:50051", grpc.WithInsecure())
if err != nil {
log.Fatalf("No se pudo conectar: %v", err)
}
defer conn.Close()
// El cliente real usaría un cliente generado: client := orderpb.NewOrderServiceClient(conn)
fmt.Println("Cliente conectado. Ejecutando llamadas...")
// Demostración de uso de Context para timeout
ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
defer cancel()
// Nota: En un código real, llamarías a client.GetOrder(ctx, &req)
// Aquí solo mostramos cómo se gestiona el ciclo de vida.
fmt.Println("Llamada Unary completada (simulada)")
fmt.Println("Streaming completado (simulado)")
}
Desglose del ejemplo
- Toolchain y
buf: Aunque en el código no se vea el comando, en un flujo de trabajo profesional no usasprotocdirectamente. Usasbuf.bufgestiona el linting de tus archivos.proto, asegura que no rompas la compatibilidad de los esquemas y simplifica la generación de código para todos los lenguajes. - Interceptors: En el servidor, hemos implementado
unaryLoggingInterceptor. Esto es equivalente a un middleware en un servidor web. En producción, aquí es donde integras OpenTelemetry para trazabilidad distribuida o para registrar métricas de latencia sin ensuciar la lógica de negocio en cada función. - Gestión de
context.Context: Fíjate en elselectdentro deGetOrder. En sistemas distribuidos, si el cliente corta la conexión o el timeout se alcanza, el servidor debe dejar de trabajar inmediatamente. Ignorarctx.Done()en un servicio que hace consultas pesadas a la base de datos es una causa común de agotamiento de recursos. - Streaming: La función
StreamOrdersdemuestra la capacidad de gRPC para mantener una conexión abierta y enviar múltiples respuestas en una sola llamada, ideal para feeds de datos en tiempo real o procesos de exportación masiva.
El error frecuente
Un error crítico en la evolución de sistemas con Protobuf es la reutilización de números de campo.
Si tienes un mensaje definido así:
message User {
string id = 1;
string name = 2;
}
Y decides cambiarlo a:
message User {
string id = 1;
int32 age = 2; // ¡ERROR! Cambiaste el tipo y el número de 'name'
}
Cuando un cliente antiguo (que espera name como string en la posición 2) reciba este mensaje, la deserialización fallará o, peor aún, interpretará los datos erróneamente si el tipo es compatible (como un int y un enum), corrompiendo la lógica de negocio sin lanzar un error explícito de inmediato. La regla de oro es: nunca cambies el número de un campo ni su tipo; si algo cambia, crea un nuevo campo con un nuevo número.
N° 230