Differential: RPC com segurança de tipos que parece funções locais

Semântica de Idempotência e Entrega

• Grande parte da discussão debate o recurso de “idempotência”.
• Críticos argumentam que a estrutura não pode tornar funções arbitrárias com efeitos verdadeiramente idempotentes; no máximo, ela pode oferecer semântica de no máximo uma vez ou no mínimo uma vez, não exatamente uma vez.
• Segundo relatos, o sistema usa chaves de idempotência mais um lock/lease; para funções marcadas como idempotentes, ele visa no máximo uma vez, emitindo a chamada apenas uma vez para um worker. Se não estiver marcado, chamadas com falha podem ser repetidas em outra máquina (no mínimo uma vez).
• Vários comentaristas dizem que a documentação e o marketing misturam essas distinções e correm o risco de enganar os usuários, especialmente quando os exemplos envolvem pagamentos.
• Alguns sugerem renomear o recurso para algo como “tryOnce” ou “retry policy” em vez de “idempotency”.

Tratamento de Erros, Repetições e IA

• Erros são expostos como exceções em funções assíncronas; timeouts causados por respostas perdidas são tratados de forma semelhante.
• Há um recurso de IA chamado “predictive retries” que classifica erros (por exemplo, resets de conexão, deadlocks) como transitórios e tenta novamente automaticamente.
• Isso é opcional e atualmente é um switch global (por cluster); alguns argumentam que deveria ser por função e questionam o valor da IA aqui em comparação com anotações explícitas.
• Preocupação: se a IA classificar incorretamente uma operação não idempotente como passível de repetição, efeitos colaterais podem ser aplicados duas vezes.

Abstração de RPC e Preocupações com Sistemas Distribuídos

• Muitos criticam o slogan “parece funções locais”, alertando que esconder realidades de rede (latência, falha parcial, partições) historicamente leva a monólitos distribuídos frágeis.
• Outros dizem que ergonomia de RPC é aceitável desde que os desenvolvedores continuem cientes de que estão em “território de sistemas distribuídos”.
• Há um debate mais amplo sobre se tornar chamadas remotas fáceis incentiva arquiteturas ruins ou se capacita equipes que já escolheram microserviços.

Arquitetura, Escopo e Serialização

• O produto é descrito como RPC com segurança de tipos para backend/microservices, com um plano de controle centralizado orquestrando chamadas, retries e verificações de saúde (em cluster para disponibilidade).
• Alguns o veem como “trpc/rspc + service mesh”; outros o chamam de “service mesh com firulas e recursos extras”.
• Ele é priorizando TypeScript, o que levanta preocupações para ambientes poliglotas versus sistemas baseados em IDL como gRPC.
• Os argumentos atualmente precisam ser JSON-serializáveis; funções/promises ainda não são suportadas. Críticos dizem que isso omite as partes mais difíceis de construir um verdadeiro runtime de linguagem distribuída (closures, aliasing, semântica de mutação).

Recepção e Maturidade

• Vários comentaristas acham a ideia interessante e observam sistemas internos semelhantes em grandes empresas.
• Muitos criticam a documentação/marketing pouco claros ou exagerados, especialmente em torno de idempotência e garantias de confiabilidade, mas reconhecem que o projeto é inicial e ainda está evoluindo.