Differential: RPC seguro de tipos que se siente como funciones locales

Idempotencia y semánticas de entrega

• Gran parte del hilo debate la función de “idempotencia”.
• Los críticos argumentan que el framework no puede volver verdaderamente idempotentes funciones arbitrarias con efectos; como mucho puede ofrecer semánticas de como máximo una vez o al menos una vez, no exactamente una vez.
• Según se informa, el sistema usa claves de idempotencia más un bloqueo/lease; para las funciones marcadas como idempotentes, aspira a como máximo una vez al emitir la llamada solo una vez a un worker. Si no se marcan, las llamadas fallidas pueden reintentarse en otra máquina (al menos una vez).
• Varios comentaristas dicen que la documentación y el marketing difuminan estas distinciones y corren el riesgo de engañar a los usuarios, especialmente cuando los ejemplos implican pagos.
• Algunos sugieren renombrar la función a algo como “tryOnce” o “retry policy” en lugar de “idempotency”.

Manejo de errores, reintentos y IA

• Los errores se exponen como excepciones en funciones asíncronas; los timeouts por respuestas perdidas se tratan de forma similar.
• Existe una función de “reintentos predictivos” basada en IA que clasifica errores (p. ej., reinicios de conexión, bloqueos mutuos) como transitorios y reintenta automáticamente.
• Esto es opt‑in y actualmente un interruptor global (por clúster); algunos argumentan que debería ser por función y cuestionan el valor de la IA aquí frente a anotaciones explícitas.
• Preocupación: si la IA clasifica mal una operación no idempotente como reintentable, los efectos secundarios podrían aplicarse dos veces.

Abstracción RPC y preocupaciones de sistemas distribuidos

• Muchos rechazan el lema “se siente como funciones locales”, advirtiendo que ocultar las realidades de la red (latencia, fallo parcial, particiones) históricamente conduce a monolitos distribuidos frágiles.
• Otros dicen que una ergonomía tipo RPC está bien mientras los desarrolladores sigan siendo conscientes de que están en “tierra de sistemas distribuidos”.
• Hay un debate más amplio sobre si hacer que las llamadas remotas parezcan fáciles fomenta arquitecturas malas o empodera a los equipos que ya han elegido microservicios.

Arquitectura, alcance y serialización

• El producto se describe como RPC seguro de tipos para backend/microservicios con un plano de control centralizado que orquesta llamadas, reintentos y comprobaciones de salud (en clúster para disponibilidad).
• Algunos lo ven como “trpc/rspc + service mesh”; otros lo llaman “service mesh con adornos”.
• Está centrado primero en TypeScript, lo que plantea preocupaciones para entornos poliglota frente a sistemas basados en IDL como gRPC.
• Los argumentos deben ser actualmente JSON-serializables; las funciones/promesas aún no están soportadas. Los críticos dicen que esto omite las partes más difíciles de construir un verdadero runtime de lenguaje distribuido (closures, aliasing, semántica de mutación).

Recepción y madurez

• Varios comentaristas encuentran la idea interesante y señalan sistemas internos similares en grandes empresas.
• Muchos critican la documentación/marketing poco claros o demasiado ambiciosos, especialmente en torno a la idempotencia y las garantías de fiabilidad, pero reconocen que el proyecto es temprano y sigue iterando.