What's new in AMF 5.6.0
AVRO Support in AMF
We're happy to announce we've added support for AVRO Schema 1.9.0 in AMF:
- as a standalone document
- inside Async APIs
an AVRO Schema has the following properties:
- It's defined in a
.json
or.avsc
file - It doesn't have a special key that indicates it's an AVRO Schema, nor it's version (like JSON Schema does with it's
$schema
)
Where we support and DON'T support AVRO Schemas
We Support AVRO Schemas (inline or inside a $ref
):
- as a standalone document or file
- we encourage users to use the
.avsc
file type to indicate that's an avro file - must use the specific
AvroConfiguration
- we encourage users to use the
- inside a message payload in an AsyncAPI
- the key
schemaFormat
MUST be declared and specify it's an AVRO payload
- the key
- an
AvroSchemaDocument
can only be parsed with the specificAvroConfiguration
We don't support AVRO Schemas:
- inside components --> schemas in an AsyncAPI
- because we can't determine if it's an AVRO Schema or any other schema
Known AVRO Validation limitations
We're using the Apache official libraries for JVM and JS. The validation libraries differ in interfaces and implementations, and each has some known constraints:
JVM avro validation constraints
- validation per se is not supported, we try to parse an avro schema and throw parsing results if there are any
- this means it's difficult to have location of where the error is thrown, we may give an approximate location from our end post-validation
- when a validation is thrown, the rest of the file is not being searched for more validations
- this is particularly important in large avro schemas, where many errors can be found but only one is shown
Both JVM & JS validation constraints
"default"
values are not being validated when the type isbytes
,map
, orarray
- the validator treats as invalid an empty array as the default value for arrays (
"default": []
) even though the Avro Schema Specification has some examples with it - if an avro record has a field that is a union that includes the root record itself (recursive reference) we fail to validate it correctly because we treat that shape as an unresolved/undefined shape. This only applies to the field inside the record, when validating the complete record the library validates correctly. In the future we'll try to ignore the cases that we are now failing and/or show a warning instead
More information here
for more information on how to use AVRO in amf check the adrs/0014-avro-support.md
file.
Full Changelog: 5.5.4...5.6.0