The New Era Approaches

Jonas Lagoni

ยท6 min read

Back in March 2022, you heard the first official words around AsyncAPI 3.0. Since then, a lot of people have been working diligently across many expertise to bring it to life. And with its current state, it's finally time to give an update on the progress.

Show Me the Money!

We are not going to give any lengthy description of features, fixes, and changes. Instead, I will just show you the money as a teaser. ๐Ÿ˜‰

Below is an AsyncAPI v3 document that defines how you, a public application, can interact with my Smartylighting Streetlights system, where you can turn on a specific streetlight through WebSocket and get real-time information about environmental lighting conditions through Kafka.

See how many features you can spot just from this example. Some changes are absent in the example, but I tried to cramp as many changes into it as possible. Below the example is a short list of changes you'll be able to fact-check your guess with.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
asyncapi: "3.0.0"
info:
  title: Smartylighting Streetlights public API
  version: "1.0.0"
  description: |
    The Smartylighting Streetlights public API allows you to remotely manage the city lights through Kafka and WebSocket.

    ### Check out its awesome features:

    * Turn a specific streetlight on ๐ŸŒƒ
    * Receive real-time information about environmental lighting conditions ๐Ÿ“ˆ
  license:
    name: Apache 2.0
    url: https://www.apache.org/licenses/LICENSE-2.0

servers:
  kafka:
    host: test.mykafkacluster.org:8092
    protocol: kafka-secure
    description: Test Kafka broker
    security:
      - $ref: '#/components/securitySchemes/saslScram'
  websocket:
    host: test.websocket.org:1999
    protocol: ws
    description: Test WebSocket server

defaultContentType: application/json

channels:
  turnStreetlightOnChannel:
    address: "/"
    messages:
      turnOn: 
        $ref: "#/components/messages/turnOn"
    servers:
      - $ref: "#/servers/websocket"

  turnStreetlightOnReplyChannel:
    address: "/"
    messages:
      turnOnReply: 
        $ref: "#/components/messages/turnOnReply"
    servers:
      - $ref: "#/servers/websocket"

  lightMeasured:
    description: The topic on which measured values may be produced and consumed.
    address: "smartylighting.streetlights.1.0.event.{streetlightId}.lighting.measured"
    parameters:
      streetlightId:
        $ref: "#/components/parameters/streetlightId"
    messages:
      lightMeasured: 
        $ref: "#/components/messages/lightMeasured"
    servers:
      - $ref: "#/servers/kafka"

operations:
  turnOn:
    action: send
    operationId: turnOn
    channel:
      $ref: "#/channels/turnStreetlightOnChannel"
    reply:
      channel:
        $ref: "#/channels/turnStreetlightOnReplyChannel"

  lightMeasured:
    action: receive
    summary: Inform about environmental lighting conditions of a particular streetlight.
    operationId: receiveLightMeasurement
    channel:
      $ref: "#/channels/lightMeasured"
    traits:
      - $ref: "#/components/operationTraits/kafka"

components:
  messages:
    turnOn:
      name: turnOn
      title: Turn on
      summary: Command a particular streetlight to turn the lights on.
      payload:
        $ref: "#/components/schemas/turnOnPayload"

    turnOnReply:
      name: turnOnReply
      title: Turn on reply
      summary: Reply from turning on the lights
      payload:
        $ref: "#/components/schemas/turnOnReplyPayload"

    lightMeasured:
      name: lightMeasured
      title: Light measured
      summary: Inform about environmental lighting conditions of a particular streetlight.
      contentType: application/json
      traits:
        - $ref: "#/components/messageTraits/commonHeaders"
      payload:
        $ref: "#/components/schemas/lightMeasuredPayload"

  schemas:
    turnOnPayload:
      type: object
      properties:
        streetlightId:
          description: The ID of the streetlight.
          type: string
        sentAt:
          type: string
          format: date-time
          description: Date and time when the request was sent

    turnOnReplyPayload:
      type: object
      properties:
        turnedOnTimestamp:
          type: string
          format: date-time
          description: Date and time when the light was actually turned on.

    lightMeasuredPayload:
      schemaFormat: "application/vnd.apache.avro;version=1.9.0"
      schema:
        type: record
        name: User
        namespace: com.company
        doc: User information
        fields:
          - name: lumens
            type: int
          - name: sentAt
            type: timestamp_ms

  securitySchemes:
    saslScram:
      type: scramSha256
      description: Provide your username and password for SASL/SCRAM authentication

  parameters:
    streetlightId:
      description: The ID of the streetlight.

  messageTraits:
    commonHeaders:
      headers:
        type: object
        properties:
          my-app-header:
            type: integer
            minimum: 0
            maximum: 100

  operationTraits:
    kafka:
      bindings:
        kafka:
          clientId: public

As of the pre-release v3.0.0-next-major-spec.12, this is a valid AsyncAPI document. You can always find the most recent pre-release version here: https://www.asyncapi.com/docs/reference.

All the changes in 3.0 up until now are the following:

  • Request/reply pattern.
  • Introduce the new Channel Object, detached from operations.
  • Introduce the new Operation object, detached from channels.
  • Channels are no longer identified with address/topic/path.
  • Optional channels.
  • Schemas and schema formats are now naturally bound.
  • Cleaned up the root object.
  • Added additional meta fields for Server Object, Channel Object, Operation Object, and Operation Trait Object.
  • External Documentation Object and Tag Object can now be reused and referenced.
  • Unified referencing behavior.

In due time we will give you a complete rundown about all the changes in 3.0 and extended documentation that explains the features in more in-depth, including a migration guide and release blog post.

The Remaining Effort

The specification work is nearly done; only one change is still being discussed which is changing traits behavior to an inheritance that can be overwritten.

However, at AsyncAPI, a specification is nothing without documentation and tools, which is why the majority of the remaining effort resolves just that.

For documentation, you have probably noticed that since the first release of 2.0, we now have concepts, tutorials, and guides. Some of those docs will be updated due to 3.0.

Regarding tooling, it's impossible to give you a clear overview of what exactly will support 3.0 right out the gate because there are many different code owners and contributors with individual priorities. So if you want a tool to support 3.0 right out the gate, please do head over to the issue and voice the need, add a ๐Ÿ‘, write a comment, or maybe even contribute the needed changes!

The only tools we can say for sure that will support 3.0 right out the gate are the JS parser and the specification JSON Schema documents because they need to be updated for any specification change to be accepted ๐Ÿ˜†

Currently, we are using completed tasks as the release date for 3.0. Once all tasks are completed, we'll release 3.0.

Release Date

That leaves the big question... When is the release then?

Honestly, we tried to stick with a release date, and more specifically, we thought the July release period (yes, next month). However as you can probably guess with the remaining work, that's most likely not going to happen. As we are learning, major changes take time, and schedules in open source are, hard, to say the least. ๐Ÿ˜„

While all the specification changes are most likely done by July, my best guess, right now, is for everything to be released in September.

The more people help out, the faster it will get done. ๐Ÿ˜‰

The next time you will hear from me will be the release blog post for 3.0. ๐Ÿ‘‹

Photo by Tim Marshall on Unsplash