Rethink `KafkaProducer`/`KafkaProducerConnection`

I’ve been thinking about how we can simplify the most common use cases.

KafkaProducerConnection really represents an untyped Kafka producer - it easily could, and possibly should, have a method produce[P, K: Deserializer, V: Deserializer](producerRecords: ProducerRecords[P, K, V]). KafkaProducer is really nothing more than a partial application of that general produce method.

I suggest that in 3.0 we rename KafkaProducerConnection to KafkaProducer and KafkaProducer to SerializingKafkaProducer.

I also suggest we add KafkaTopicProducer, which has both serializers and a topic name provided on instantiation and takes just key-value pairs rather than ProducerRecords as arguments for its produce method. This would simplify calling code in, I think, the great majority of use cases.

Further, there could be a variant that automatically derives keys from values (typically the key would be the same as some kind of id field from the value), so that calling code only needs to provide the value and not the key.

The main drawback I see is that the resulting number of variants could cause confusion, but I think careful API design would mitigate that.

Any thoughts? @vlovgr @LMnet

[LMnet]

What about leaving KafkaProducer as it is and renaming KafkaProducerConnection to GenericKafkaProducer?

Sounds good for me.

a function mkKey: V => K for deriving it would be provided when the consumer is instantiated.

After the first reading, I thought you are talking about typeclass to derive a key from the value. Simple function sounds better in this context because it’s explicit and simple.

[LMnet]

How about we rename KafkaProducerConnection to GenericKafkaProducer for 2.0, with a deprecated type alias as KafkaProducerConnection? Then the change should be mostly source-compatible, and it doesn’t matter that it’s binary breaking.

Ok