Serialization API proposal cont.

[mtmk]

https://github.com/nats-io/nats.net.v2/blob/serialization-api-change-proposal-2/docs/documentation/serialization.md

(Docs to be updated in a later PR)

Summary

• Added serializer parameter to all publish, subscribe and consume calls alike
• Now serializer interface is generic INatsSerializer<T>
• New interface INatsSerializerRegistry for connection wide serialization settings
• Removed many of the unnecessary nullables e.g. <T?> -> <T>

Details

This is the continuation of the previous proposal where simplified the serialization APIs and made them compatible with native AOT deployments.

With this change, we make it more obvious where to pass the serializer into various calls. We also made the interface generic to make it easier to implement in a type safe manner.

The main change is that the serializer option is removed from NatsSubOpts and NatsPubOpts classes and became a parameter in publish and subscribe calls (as well as in all JS / KV / Obj / Svc etc. calls):

var myJson = new NatsJsonContextSerializer(MyJsonContext.Default);

await using var sub = await nats.SubscribeAsync<MyData>(subject: "foo", serializer: myJson);

await nats.PublishAsync<MyData>(subject: "foo", data: new MyData { Id = 1, Name = "bar" }, serializer: myJson);

This makes it easier to pass in different serializers in every call, especially in native AOT deployments.

We also introduce a serializer registry concept to be used as a connection wide serialization mechanism. This was necessary with INatsSerializer<T> being generic and since we can't know the type in advance. It's very simple and can be passed in with NatsOpts.Serializers property:

public interface INatsSerializerRegistry
{
    INatsSerializer<T> GetSerializer<T>();
}

So we have the additional flexibility with INatsSerializerRegistry on top of being able to chain multiple INatsSerializer<T>s.

Also fixes #142

[mtmk]

@jasper-d you'd be interested 💯

[jasper-d]

@jasper-d you'd be interested 💯

I'll take a look tomorrow this weekend.

[jasper-d]

Thank you, I think this is a good compromise to support both, serializers passed directly and serializers attached to a connection.

[jasper-d]

Would it make sense to split INatsSerializer<T> into I(Nats)Serializer<T> and I(Nats)Deserializer<T> now? Presumably one is often not going to send and receive the same type but the current interface requires an implementation for both.

[jasper-d]

Which then also raises the question if it wouldn't be better (and feasible) to just use Action<IBufferWriter<byte>, T> and Func<ReadOnlySequence<byte>, T> so that clients don't have to implement the interface if they already have a suitable serializer that matches the delegates signature.

[mtmk]

Sounds ok but I'd like to see what @caleblloyd would say here.

[caleblloyd]

Splitting into I(Nats)Serializer<T> and I(Nats)Deserializer<T> makes sense to me

The Action / Func seems a little non-standard - it may map cleanly to some Serializer/Deseriaizers such as GRPC, but not others, such as JsonSerializer. It should be trivial to use a helper function to create a static I(Nats)Serializer<T> and I(Nats)Deserializer<T> from an Action / Func though

[mtmk]

I agree we can split the interface but I'm leaning towards interfaces too rather than action/func approach. I believe interface would be more developer friendly in general.

[mtmk]

I will be updating the docs in the release prep PR

[caleblloyd]

I like the interface splitting, but might I suggest some clarity on naming:

• INatsSerialize- the serialize half of a serializer
• INatsDeserialize - the deseialize half of a serializer
• INatsSerializer: implements INatsSerialize, INatsDeserialize

Then for parameter naming what is your opinion of calling all of the params that deal with Serialize/Deseialize serializer? Even though they will be typed as INatsSerialize or INatsDeserialize. Most people will just want to provide a Serializer that can do either

[caleblloyd]

A couple docs fixes, then LGTM!