KafkaJS interface usability friction

[kylevogt]

Our organization currently uses KafkaJS with a private 'wrapper' library that we maintain internally that takes care much of our boilerplate usage around kafka such as emitting metrics, error handling, config mapping/defaulting, etc. I've noticed some friction with trying to use this confluent library that I don't typically experience with javascript libraries.

The first friction I ran into was the library throwing errors when there were "extra" configurations on the KafkaJS configuration object being passed in. I would expect most javascript libraries to simply ignore any extra properties. Or, at the very most log a warning about an unsupported property being included. I do understand the intention here. There are some KafkaJS configurations that are not supported and ensuring users don't expect those configs to be working is valuable. I think a warning log rather than a runtime error would be preferable here however.

The second bit of friction I ran into was the library throwing errors when a property exists on the config object but does not have a value. It's very common when mapping javascript objects/configs to "set" all config properties but have many of them be undefined. When there are undefined properties it is generally expected that they will simply be ignored. Rather than using Object.hasOwn(kjsConfig, 'metadataMaxAge') on it's own to determine if a value should be set, I'd suggest also ensuring the value !== undefined as well before adding the config key to pass to librdkafka.

I'm more than happy to expand on any of these ideas if they aren't clear. I appreciate the work going into this library particularly with KafkaJS maintainorship in flux.