A Dor Real — Onde REST Começa a Te Cobrar a Conta
O problema nunca foi o HTTP. O problema é usar REST como se fosse a solução universal. Em sistemas distribuídos, REST vira um dinossauro: verboso, lento, difícil de versionar e frágil quando o tráfego cresce. **A cada JSON gigante trafegado, nasce um pouco mais de dívida técnica.**
REST funciona para fronteiras externas (APIs públicas), mas dentro da sua malha de serviços ele te deixa na mão: over-engineering em gateways, explosão de endpoints, latência previsível (e alta). Tudo isso enquanto o negócio exige respostas em milissegundos.
A Solução Pragmática — gRPC Como Camada de Nervos da Arquitetura
gRPC resolve a dor onde REST sangra. Binário, rápido, com contrato forte via Protobuf e suporte nativo a streaming. Nada de payloads inflados ou ambiguidade de contrato. **É ferramenta de gente que quer entregar e não ganhar prêmio de arquitetura bonita.**
Para comunicação interna, gRPC é simplesmente superior. Para APIs externas? REST ou GraphQL ainda têm seu lugar. Simples assim.
Implementação de Sênior — gRPC Sem Frescura na Prática
Aqui vai um exemplo funcional usando um contrato Protobuf simples e o servidor em Go. Sem cerimônia.
// service.proto
syntax = "proto3";
package warehouse;
service InventoryService {
rpc CheckStock (StockRequest) returns (StockResponse);
}
message StockRequest {
string product_id = 1;
}
message StockResponse {
int32 quantity = 1;
}// server.go
package main
import (
"context"
"log"
"net"
pb "warehouse/proto"
"google.golang.org/grpc"
)
type server struct{
pb.UnimplementedInventoryServiceServer
}
func (s *server) CheckStock(ctx context.Context, req *pb.StockRequest) (*pb.StockResponse, error) {
qty := 42
return &pb.StockResponse{Quantity: qty}, nil
}
func main() {
ln, err := net.Listen("tcp", ":50051")
if err != nil { log.Fatal(err) }
grpcServer := grpc.NewServer()
pb.RegisterInventoryServiceServer(grpcServer, &server{})
log.Println("gRPC rodando na porta 50051...")
grpcServer.Serve(ln)
}Compacto, rápido e com contrato explícito. **É assim que se reduz ruído em time de produto.**
O Custo da Escolha — Nem Tudo é Arco-Íris no gRPC
gRPC não é bala de prata. Se você expõe API pública, REST ainda vence pela simplicidade e compatibilidade universal. Ferramentas de observabilidade também não são tão maduras quanto as de REST. Sem contar infra: load balancers HTTP/2 precisam estar bem configurados para não virar gargalo.
Mas no fim do dia, o custo de manter REST em comunicação interna é maior. A conta aparece em latência, instabilidade e retrabalho.
Direto das Trincheiras — 3 Dicas Rápidas
- Use gRPC apenas na comunicação interna. Expor gRPC diretamente ao público é pedir dor de cabeça.
- Mantenha os .proto versionados e imutáveis após publicados. Contrato é contrato.
- Automatize a geração de clients no CI. Evita drift e elimina bug besta.
Fontes
Não foram incluídas fontes externas, pois as fornecidas não eram relacionadas ao tema deste artigo, conforme solicitado.
Obrigado por acompanhar essa reflexão até o fim!
Espero que esses pontos ajudem você a tomar decisões mais lúcidas no seu próximo projeto. Não deixe de conferir outros artigos aqui no blog reymaster.dev.br, onde descascamos outros hypes da área.
Valeu e até a próxima! 😉
