Cuando trabajas con DAPR y estas en un código objetos POCO cuando lo envia al sidecar debe transformar el POCO a PROTO.
Problema
Tienes un objeto POCO muy grande y complejo, e incluso si me apuras mediano y no tan complejo… este objeto debe se transformado en el sidecar de un Service2Service a PROTO para que el otro microservicio de DAPR lo interprete y a su vez lo debe transforma de PROTO a POCO.
Resultado
Este baile de transformaciones consume muchos ms y en sistemas de alta demanda te han metido tu solo un problema con fácil solución, pero si no te lo cuenta, no sabrías porque está tardando tanto tiempo en la comunicación.
Solución
Nada más fácil que hacer que el mensaje que pasas sea un Base64 con un solo objeto y cuando llega al otro servicio solamente tienes que hacer una decodificación y mapearlo al objeto.
Esta solución es para salir del paso, pero aún sigue siendo una solución que te consume ms, no tantos como lo que tiene que hacer para pasar de POCO a PROTO, en este caso es un Base64 con una propiedad (body, por ejemplo) que luego debe ser decodificada.
Como ves metes un Lag, pero no tanto como el problema original.
Lo que me lleva a decirte, que debe usar gRPC y ganar la verdadera velocidad que nos ofrece DAPR.
Conclusión
Espero haber dado una solución a un problema que se dio en producción.
Un problema real que demuestra que lo mejor es trabajar con los protocolos originalmente para lo que se diseña un producto y que cualquier otra solución no deja de ser workarround temporal.
