optimize NATS message sending and receiving logic by using the nats.Msg struct instead of the original

[jiyeyuran]

No description provided.

[asim]

By making this change doesn't it break backwards compatibility?

[jiyeyuran]

I'm afraid that the messages of the new transport and the old transport cannot be parsed by each other, so a smooth upgrade cannot be achieved.

[asim]

It's hard to accept a change like that for existing users. They have no upgrade path. We can't leave them with this sort of breaking change in the event they upgrade and it destroys all their production traffic without understanding what's happened. If you can define a clear upgrade path of backwards compatibility we can accept it. E.g if you define a header for protocol version in the nats headers and we find this header, then we know the correct way to parse out the new version of the encoding versus the old way.

[asim]

I know you're trying to simplify the code but without the deadline any Send will essentially block forever if there's a problem. If you are specifically looking for the optimisation of not marshalling then we need to do as I mentioned which is specifying a protocol header which can be checked and then choose the two code paths for either the old unmarshalling or new way

[jiyeyuran]

Sorry, my mistake — I just undo the last commit. Since PublishMsg in NATS is non-blocking, I’d like to simplify the code. I forgot to check out a new branch.

[jiyeyuran]

I know you're trying to simplify the code but without the deadline any Send will essentially block forever if there's a problem. If you are specifically looking for the optimisation of not marshalling then we need to do as I mentioned which is specifying a protocol header which can be checked and then choose the two code paths for either the old unmarshalling or new way

Do you mean to add a special key in header of transport.Message?

[asim]

Yea but then you need to add it to the nats message header when you're switching and when receiving any messages you need to check for that header and if it's there you know it's the new message format and if it's not there then it's the old one.

E.g

Micro-Transport=NATS-v2

If you find this header you know it's the new transport otherwise you unmarshal the JSON the old way. But this will mean old services are not compatible with new ones anyway because they won't be able to process the new header but at least it'll be forward compatible

[jiyeyuran]

@asim Can we determine whether it is a new transport by checking the presence of a NATS header? The NATS header of the new transport must not be empty, while the NATS header of the old transport is always empty.

[asim]

So by doing that any service using the new transport will be backwards compatible. It's just that any old service that receives a message from the new transport without having sent one first will not be able to decode the message. So it is a breaking change from that perspective. I don't think there's any way to reliably get around that without the new service having broader awareness of the services, transports, protocols, etc. it has to potentially inspect the registry before hand and select the correct transport which is maybe assuming too much for this PR.

[jiyeyuran]

We need a mechanism that negotiates the encoding protocol when the client and server establish a connection, and only then proceeds with communication.