nats.go
nats.go copied to clipboard
Allow to use `SubscribeSync` for `EncodedConn`
Feature Request
API of EncodedConn
is inconsistent with Conn
which is confusing for users.
Use Case:
Single message passed to handler.
I don't want to encode data manually with nats.Conn
would love to see SubscribeSync
Proposed Change:
Who Benefits From The Change(s)?
Alternative Approaches
Use Conn
and mess with Marshalling / Unmarshalling data.
It’s perhaps worth noting that the encoded connections idea is essentially deprecated and incompatible with streams etc.
We have decided to take a look at it later and come up with something differrent that meets current needs better.
So you might want to consider if investing in using them now is a good idea.
Hi @ripienaar thanks for quick reply - Docs from nats.go client doesn't say a word about any deprecations?
Is there any NATS idiomatic way than to automatically encode/decode messages? Or should I do all codec logic by myself?
I am not sure if its widely communicated as you say - for now I would suggest to do it in your code, tends to be not that big a deal.