Should serdes functionality be exported to JS?

[mostafa]

Instead of implicitly calling the serdes functions via produce and consume, we can explicitly call them from JS and have the user control over them. This way, we can have a more flexible serializer/deserializer system, and we don't need to worry about API changes and backward compatibility. Also, we won't have to decide when to use the serializer/deserializer based on the schema and given parameters.

[enamrik]

@mostafa I like that idea. So, for example, instead of the consume method taking a keySchema and valueSchema, it would take optional key and value serializers. We could have a serde interface like:

type SerdeInterface interface {
	serialize(model interface{}) []byte
	deserialize(data []byte) interface{}
}

and consume method:

func (k *Kafka) Consume(reader *kafkago.Reader, limit int64,
	keySerializer SerdeInterface, valueSerializer SerdeInterface) ([]map[string]interface{}, *Xk6KafkaError) 

We may not need the ConsumeWithConfiguration anymore since most of the configuration would be passed to the SerdeInterface implementation.

Is this what you were thinking? If so, I could take a shot at it. Let me know.

[mostafa]

@enamrik
I was thinking along the same lines as what you mentioned. However, I want to pass values directly from JS to Go in functions as JSON. So, I'll move all the function parameters into one or many JSON object(s), which is what I did with SASL and TLS configs in #86. I also created #89 to discuss the future API changes. Feel free to add your suggestions there and then link to the relevant PR.

[enamrik]

@enamrik I was thinking along the same lines as what you mentioned. However, I want to pass values directly from JS to Go in functions as JSON. So, I'll move all the function parameters into one or many JSON object(s), which is what I did with SASL and TLS configs in #86. I also created #89 to talk about the future API changes. Feel free to add your suggestions there and then link to the relevant PR.

Oh I see. So you would pass keyConfig and valueConfig JSON objects and those configuration objects would describe the serde type and serde input configuration. Sounds good.