differentiate between pass-through and byte[] for DaprObjectSerializer

Expected Behavior

byte[] can means 2 things.

• pass-through: do not serialize/deserialize the values. Sent/return the raw data. Other parts of the system will deal with raw data.
• normal byte[] values: serialize/deserialize them normally.

Actual Behavior

Current DaprObjectSerializer does not differentiate between pass-through byte[] and normal byte[] values. The DefaultObjectSerializer treats byte[] as always pass-through.

There are cases when serializing/deserializing byte[] as normal values is desired. For example, for json, it’s desired to serialize byte[] as base64-encoded String because there’s no other way to represent byte[] as legal JSON values.

I suggest to change the DaprObjectSerializer to follows:

public interface DaprObjectSerializer {
    default byte[] serialize(Object o) throws IOException {
        // passThrough by default true, to make this not a breaking change.
        return serialize(o, true);
    }

    byte[] serialize(Object o, boolean passThrough) throws IOException;

    default <T> T deserialize(byte[] data, TypeRef<T> type) throws IOException {
        return deserialize(data, type, true);
    }

    <T> T deserialize(byte[] data, TypeRef<T> type, boolean passThrough) throws IOException;

    String getContentType();
}

and DefaultObjectSerializer should be changed to honor explicit passThrough param.

Steps to Reproduce the Problem

Release Note

RELEASE NOTE:

[xiazuojie]

@xiazuojie Can the same be accomplished with a different DaprClient instance per serializer? The original design was that for apps that need multiple serializers, they could simply instantiate a different DaprClient.

Yes. It’s the workaround we are currently using. But it’s not ideal.

https://github.com/dapr/dapr/issues/2905#issuecomment-796537346: The users are forced to work around this by treating raw byte[] as "skipping serialization", which brings another issue. Another workaround (the one we are currently using) is creating multiple instances of Dapr client with different DaprObjectSerializer in order to work with different components.

[xiazuojie]

To support serialization negotiation (https://github.com/dapr/dapr/issues/2905), I suggest the DaprObjectSerializer interface to be changed to:

public interface DaprObjectSerializer {

  /**
   * Serializes the given object as byte[].
   *
   * @param o Object to be serialized.
   * @return Serialized object.
   * @throws IOException If cannot serialize.
   */
  byte[] serialize(Object o) throws IOException;

  /**
   * Deserializes the given byte[] into a object.
   *
   * @param data Data to be deserialized.
   * @param type Type of object to be deserialized.
   * @param <T> Type of object to be deserialized.
   * @return Deserialized object.
   * @throws IOException If cannot deserialize object.
   */
  <T> T deserialize(byte[] data, TypeRef<T> type) throws IOException;

  /**
   * Whether the serializer supports the given MIME type of the source data
   */
  boolean canSerialize(MimeType mimeType);

  /**
   * Whether the serializer supports the given source element type and the MIME type for the output data
   */
  <T> boolean canDeserialize(TypeRef<T> type, MimeType mimeType);
}

• getContentType() method is removed. Content type (a.k.a. mimeType) should be a property (data-content-type) for the input byte[] and output byte[], not the serializer.
• canSerialize() and canDeserialize() are added to support serialization negotiation based on data-content-type.
• Instances of DaprObjectSerializer with multiple serialization methods can be used. The actual DaprObjectSerializer instance should be chosen based on mimeType support and rules of order.