Differential: RPC seguro de tipos que se siente como funciones locales
Un nuevo framework RPC basado en TypeScript llamado Differential promete llamadas seguras de tipos, “como funciones locales”, entre servicios, pero ha recibido escrutinio de ingenieros preocupados por ocultar los problemas difíciles de los sistemas distribuidos. Los comentaristas cuestionan sus afirmaciones sobre idempotencia, reintentos y manejo predictivo de errores basado en IA, argumentando que las semánticas de exactamente una vez y los fallos de red transparentes no pueden abstraerse de forma fiable. Los creadores responden que el proyecto es temprano, de código abierto y más parecido a un orquestador estilo service mesh, y dicen que planean aclarar las garantías y la terminología en la documentación.
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.