Por que o seu Microserviço deve permitir Integração via JSON-RPC?

Embora o REST seja o padrão absoluto para o Frontend, a comunicação entre serviços (Service-to-Service) pede algo mais direto e menos verboso.

O gRPC é frequentemente citado como a solução de elite, mas traz uma complexidade de infraestrutura (.proto, geração de código, HTTP/2) que muitos projetos não precisam no dia zero.
O JSON-RPC surge como o "pote de mel": simples como JSON, mas eficiente e intuitivo como uma chamada de função local.

Onde cada um brilha?

• REST: Perfeito para recursos públicos. Focado em substantivos (/users).
• gRPC: Ultra-performance e streaming. Focado em contratos rígidos (Binário).
• JSON-RPC: O melhor para comunicação interna ágil. Focado em ações (User.Create). É nativo em Go e não exige ferramentas externas.

Implementação Enterprise: O que não pode faltar

Para um sistema robusto, não basta apenas "rodar" o RPC. É preciso controle:

• Capabilities: O serviço deve ser capaz de se "auto-apresentar", listando métodos disponíveis via reflexão no arranque.
• Rastreabilidade: Cada chamada deve carregar um Trace-ID no Contexto para que saibas exatamente quem iniciou a cadeia de ações.
• Segurança (Internal Key): Autenticação rápida via Headers (X-Internal-Key) para garantir que apenas serviços autorizados acedam ao motor RPC.

O Desafio da Memória em Go

Um detalhe crítico ao implementar RPC em Go com transações de base de dados: Cuidado com a estabilidade dos ponteiros.

Ao usar closures (funções anónimas) dentro de transações, evita declarar ponteiros nulos para o retorno. Se tentares preenchê-los apenas dentro da transação, podes enfrentar problemas de visibilidade de memória (Race Conditions) que resultam em nil pointer dereference.

A Boa Prática: Inicializa sempre a tua struct de resposta (new(Struct) ou &Struct{}) antes de entrar na transação. aIsso garante um endereço de memória estável e evita que o teu Dispatcher RPC sofra um Panic.

Configurações e Limites

Um motor RPC robusto precisa de fronteiras claras:

• Timeouts: Controle rígido para que uma chamada não "prenda" o serviço infinitamente.
• Payload Limit: Evita que requisições gigantes saturem a memória do servidor.
• Observabilidade: Logs automáticos de cada método invocado, incluindo a latência e o status da resposta.

Conclusão

Adotar JSON-RPC na arquitetura interna reduz o overhead de roteamento, facilita o debug (é legível, ao contrário do gRPC) e mantém o código limpo.
É a escolha de quem prefere resolver problemas de negócio a lutar contra a infraestrutura.

O JSON-RPC dá ao teu sistema a fluidez de uma chamada de função com a robustez de um microserviço.