You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
Every once in a while users of KP come up with something that KP can't do or won't do easily. In this case, we want to use Avro serialization and whatnot, but we want to be able to also set the Kafka key.
If we added a parameter for every request, the signature will eventually pollute and we'll have to end up writing a v3 which I really would like to avoid.
Describe the solution you'd like
If producers accepted middleware then that middleware would be able to do anything they want. Extra metadata could be passed through context. This also means all Produce fields will now accept context.
While this does mean a breaking change, it will avoid any potential change in the future.
The question here is though: should we add middleware on UntypedProducer or a typed producer? Whatever we chose, we can then create a separate tracing middleware so that default producers are free of any tracing logic as well.
Describe alternatives you've considered
An alternative conversation went along forking the repo temporarily (because the need was temporary), it also went in adding an extra field in the Produce method. Using the untyped producer directly and exposing internal things like schema registry etc. None of them are as flexible/good as just supporting middleware while producers.
Additional context
I'm inclined towards untyped producers having middleware support, but Typed producers also expose the same method which internally calls the untyped producer as well. This way both producers can happily use middlewares.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
Every once in a while users of KP come up with something that KP can't do or won't do easily. In this case, we want to use Avro serialization and whatnot, but we want to be able to also set the Kafka key.
If we added a parameter for every request, the signature will eventually pollute and we'll have to end up writing a v3 which I really would like to avoid.
Describe the solution you'd like
If producers accepted middleware then that middleware would be able to do anything they want. Extra metadata could be passed through context. This also means all Produce
fields
will now accept context.While this does mean a breaking change, it will avoid any potential change in the future.
The question here is though: should we add middleware on UntypedProducer or a typed producer? Whatever we chose, we can then create a separate tracing middleware so that default producers are free of any tracing logic as well.
Describe alternatives you've considered
An alternative conversation went along forking the repo temporarily (because the need was temporary), it also went in adding an extra field in the
Produce
method. Using the untyped producer directly and exposing internal things like schema registry etc. None of them are as flexible/good as just supporting middleware while producers.Additional context
I'm inclined towards untyped producers having middleware support, but Typed producers also expose the same method which internally calls the untyped producer as well. This way both producers can happily use middlewares.
The text was updated successfully, but these errors were encountered: