[Schema Registry] Archboard feedback

[deyaaeldeen]

We had the archboard meeting on 9/14 and you can find the recording in Azure/azure-sdk#3303.

Feedback:

Schema Registry

• remove caching
• let's throw instead of returning an undefined in getSchema and getSchemaProperties, since the avro package will throw anyway and to be consistent with other languages
• rename endpoint to fullyQualifiedNamespace
• rename content to schemaDefinition
• rename KnownSerializationType to KnownSchemaFormat
• rename serializationType to format

Wont fix

see #17697 (comment) for details

• investigate using ArrayBuffer instead of string as the type for the content parameter and property type in Schema
• investigate perf/API implications of adding a new SchemaId type to allow the ID to be stored in bytes rather than converting to string. We can expose a toString method for debugging, and implement comparison based on the ID

Schema Registry Avro

• implement an LRU eviction policy for the existing cache to limit max entries to 128. Send an email to the archboard team with the details of the implementation once it is done.
• make groupName optional in the constructor. For context, group name is not needed to deserialize. Since you have the schema Id when deserializing, this should be enough to get the schema.
• investigate adding a serialize overload that take a schema ID as input

[deyaaeldeen]

FYI @ramya-rao-a @nguerrera

[nguerrera]

Feedback looks good. I wish could have attended but was out. A couple of notes:

let's throw instead

See #17700 (comment). The opposite change to not throw was made previously based on customer feedback.

make groupName optional in the constructor.

What will happen if you don't provide group name and you try to serialize? Throw?

[deyaaeldeen]

investigate using ArrayBuffer instead of string as the type for the content parameter and property type in Schema

This has been discussed in length with the service team and we agreed that schemas by default should be human readable so they're strings in most of the cases. The type can be reconsidered if the service supports a schema format that does not have a human readable form.

investigate perf/API implications of adding a new SchemaId type to allow the ID to be stored in bytes rather than converting to string. We can expose a toString method for debugging, and implement comparison based on the ID

This point is no longer applicable because the serializer will not use the preamble design and the schema ID will be included in the content-type header, so no bytes conversion needed.

[deyaaeldeen]

Closing this in favor of #20064