The Intricacies of a Single Keyword in AsyncAPI
summary
Explains how AsyncAPI's schemaFormat lets messages use JSON Schema (draft-07), Avro 1.9, or JSON Type Definition (JTD) and what each actually does: JSON Schema enforces runtime validation with keywords (type, const, if/then/else, not) but resists reliable code generation; Avro is designed for serialization and codegen but lacks JSON Schema's constraint power; JTD sits between and maps cleanly to types. Tooling implications: custom adapters, conflicting intent (definition vs validation), and surprising behavior from nested not constraints.
AI-written summary · about
chapters (9)
- 0:00AsyncAPI schema formats intro
- 1:07Three AsyncAPI schema formats
- 3:41Deep dive: JSON Schema
- 19:59JSON Schema for data models
- 20:19Avro schema format
- 25:57JSON Type Definition
- 29:17Schema format tooling challenges
- 30:24Schema format flexibility issues
- 32:14Closing & Q&A
related talks
27mAsyncAPI & The future of API specs
03mWhy AsyncAPI Is Essential for Modern Event-Driven Architectures
31mUnifying OpenAPI & AsyncAPI : Designing JSON Schemas+Examples.
19mValidating Event Driven Architecture (EDA) with AsyncAPI
25mThe Future of API Specifications
32mJSON Standards for the Web
39mIntroduction to AsyncAPI for Apache Kafka
22mSpecification-Driven Development of REST APIs