Differential: RPC com segurança de tipos que parece funções locais
Um novo framework RPC baseado em TypeScript chamado Differential promete chamadas seguras em termos de tipos, “como funções locais”, entre serviços, mas atraiu escrutínio de engenheiros preocupados com a tentativa de mascarar os problemas difíceis de sistemas distribuídos. Os comentaristas questionam suas alegações sobre idempotência, retries e tratamento de erros com IA preditiva, argumentando que semânticas exatamente uma vez e falhas de rede transparentes não podem ser abstraídas de forma confiável. Os criadores respondem que o projeto é inicial, open source, e mais próximo de um orquestrador no estilo de service mesh, e dizem que planejam esclarecer as garantias e a terminologia na documentação.
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.