-
Notifications
You must be signed in to change notification settings - Fork 767
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Un-deprecate NewWriter #706
Comments
Hello @alexec. The
Your program does not need to assign every single field of the Would you be able to provide examples where using the |
The specific case I found was setting up TLS, |
Aside: I think I've mentioned I want both speed and reliability, but reliability trumps speed be default. I think I need to provide a knob so users can choose between them. I believe that main way to do this would be to expose the Does this sound correct? |
Hello, This is also my concern. We also want to support TLS encryption but now in default Writer type there is, as mentioned before, no Dialer support which is used to implement TLS. And with NewWriter type will lose support in v1. Will there be TLS support implemented into Writer type? |
@nikola-sever-syntio / @alexec An example of configuring dialer with a second timeout and TLS tlsConfig := // construct tls config
kafkaWriter.Transport = &kafka.Transport{
Dial: (&net.Dialer{
Timeout: 3 * time.Second,
}).DialContext,
TLS: tlsConfig,
} |
@kishaningithub thank you |
The writer uses
The |
To add to the sentiment above, I'd say the pattern you have now allows teams to wrap configuration and provide context local defaults more easily via your WriterConfig struct. To reference a comment on the Writer:
This becomes a non-issue if you keep the WriterConfig, as from an engineer's perspective there is less of an expectation that altering a field on a config after its passed to a constructor would have an effect whereas making changes to a field directly on a Writer is something that there would be a viable change to the way it worked. As it stands at the moment, to apply local contextual config on behalf of teams I need to mirror each and everyone of your config variables if you were to remove the WriterConfig. Whereas if you keep it I can provide context local sensible defaults (cluster addresses etc) whilst still providing deep config for power users, without needing to create a mirrored setting for each Writer setting. |
Thanks for the context @adrian-mcmichael, these are interesting points that we'll take into account. |
There also seems to be an inconsistency in the api since a reader config requires a Dialer while writers require a transport. Or am I missing something? |
You are correct, this is an inconsistency we are planning to resolve in upcoming versions of the package. |
Creating a
kafka.Writer
directly seems to be much more complex that callingNewWriter
. For example, it puts into place sensible defaults, makes setting up thekafka.Dialer
for TLS really easy. I propose either:The text was updated successfully, but these errors were encountered: