+
+
-
+
@@ -188,6 +170,29 @@ function CommunityIndexPage() {
className="bg-channelCover"
/>
+
diff --git a/pages/docs/reference/specification/v3.0.0.md b/pages/docs/reference/specification/v3.0.0.md
index f4153ad73e5e..9221b67d0fa2 100644
--- a/pages/docs/reference/specification/v3.0.0.md
+++ b/pages/docs/reference/specification/v3.0.0.md
@@ -1,10 +1,10 @@
# AsyncAPI Specification
-#### Attribution
+## Attribution
Part of this content has been taken from the great work done by the folks at the [OpenAPI Initiative](https://openapis.org).
-#### Version 3.0.0
+### Version 3.0.0
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt).
@@ -63,28 +63,36 @@ Aside from the issues mentioned above, there may also be infrastructure configur
##
Definitions
###
Server
+
A server MAY be a message broker that is capable of sending and/or receiving between a [sender](#definitionsSender) and [receiver](#definitionsReceiver). A server MAY be a service with WebSocket API that enables message-driven communication between browser-to-server or server-to-server.
###
Application
-An application is any kind of computer program or a group of them. It MUST be a [sender](#definitionsSender), a [receiver](#definitionsReceiver), or both. An application MAY be a microservice, IoT device (sensor), mainframe process, message broker, etc. An application MAY be written in any number of different programming languages as long as they support the selected [protocol](#definitionsProtocol). An application MUST also use a protocol supported by the [server](#definitionsServer) in order to connect and exchange [messages](#definitionsMessage).
+
+An application is any kind of computer program or a group of them. It MUST be a [sender](#definitionsSender), a [receiver](#definitionsReceiver), or both. An application MAY be a microservice, IoT device (sensor), mainframe process, message broker, etc. An application MAY be written in any number of different programming languages as long as they support the selected [protocol](#definitionsProtocol). An application MUST also use a protocol supported by the [server](#definitionsServer) in order to connect and exchange [messages](#definitionsMessage).
###
Sender
+
A sender is a type of application, that is sending [messages](#definitionsMessage) to [channels](#definitionsChannel). A sender MAY send to multiple channels depending on the [server](#definitionsServer), protocol, and use-case pattern.
###
Receiver
+
A receiver is a type of application that is receiving [messages](#definitionsMessage) from [channels](#definitionsChannel). A receiver MAY receive from multiple channels depending on the [server](#definitionsServer), protocol, and the use-case pattern. A receiver MAY forward a received message further without changing it. A receiver MAY act as a consumer and react to the message. A receiver MAY act as a processor that, for example, aggregates multiple messages in one and forwards them.
###
Message
-A message is the mechanism by which information is exchanged via a channel between [servers](#definitionsServer) and applications. A message MAY contain a payload and MAY also contain headers. The headers MAY be subdivided into [protocol](#definitionsProtocol)-defined headers and header properties defined by the application which can act as supporting metadata. The payload contains the data, defined by the application, which MUST be serialized into a format (JSON, XML, Avro, binary, etc.). Since a message is a generic mechanism, it can support multiple interaction patterns such as event, command, request, or response.
+
+A message is the mechanism by which information is exchanged via a channel between [servers](#definitionsServer) and applications. A message MAY contain a payload and MAY also contain headers. The headers MAY be subdivided into [protocol](#definitionsProtocol)-defined headers and header properties defined by the application which can act as supporting metadata. The payload contains the data, defined by the application, which MUST be serialized into a format (JSON, XML, Avro, binary, etc.). Since a message is a generic mechanism, it can support multiple interaction patterns such as event, command, request, or response.
###
Channel
+
A channel is an addressable component, made available by the [server](#definitionsServer), for the organization of [messages](#definitionsMessage). [Sender](#definitionsSender) applications send messages to channels and [receiver](#definitionsReceiver) applications receive messages from channels. [Servers](#definitionsServer) MAY support many channel instances, allowing messages with different content to be addressed to different channels. Depending on the [server](#definitionsServer) implementation, the channel MAY be included in the message via protocol-defined headers.
###
Protocol
+
A protocol is the mechanism (wireline protocol or API) by which [messages](#definitionsMessage) are exchanged between the application and the [channel](#definitionsChannel). Example protocols include, but are not limited to, AMQP, HTTP, JMS, Kafka, Anypoint MQ, MQTT, Solace, STOMP, Mercure, WebSocket, Google Pub/Sub, Pulsar.
###
Bindings
-A "binding" (or "protocol binding") is a mechanism to define protocol-specific information. Therefore, a protocol binding MUST define protocol-specific information only.
+
+A "binding" (or "protocol binding") is a mechanism to define protocol-specific information. Therefore, a protocol binding MUST define protocol-specific information only.
##
Specification
@@ -165,7 +173,7 @@ This field represents a unique universal identifier of the [application](#defini
It is RECOMMENDED to use a [URN](https://tools.ietf.org/html/rfc8141) to globally and uniquely identify the application during long periods of time, even after it becomes unavailable or ceases to exist.
-###### Examples
+##### Examples
```json
{
@@ -207,7 +215,7 @@ Field Name | Type | Description
This object MAY be extended with [Specification Extensions](#specificationExtensions).
-##### Info Object Example:
+##### Info Object Example
```json
{
@@ -269,7 +277,7 @@ Field Name | Type | Description
This object MAY be extended with [Specification Extensions](#specificationExtensions).
-##### Contact Object Example:
+##### Contact Object Example
```json
{
@@ -298,7 +306,7 @@ Field Name | Type | Description
This object MAY be extended with [Specification Extensions](#specificationExtensions).
-##### License Object Example:
+##### License Object Example
```json
{
@@ -392,7 +400,6 @@ production:
description: "This environment is the live environment available for final users."
```
-
####
Server Object
An object representing a message broker, a server or any other kind of computer program capable of sending and/or receiving data. This object is used to capture details such as URIs, protocols and security configuration. Variable substitution can be used so that some details, for example usernames and passwords, can be injected by code generation tools.
@@ -500,7 +507,6 @@ variables:
- staging
```
-
####
Default Content Type
A string representing the default content type to use when encoding/decoding a message's payload. The value MUST be a specific media type (e.g. `application/json`). This value MUST be used by schema parsers when the [contentType](#messageObjectContentType) property is omitted.
@@ -519,11 +525,6 @@ In case a message can't be encoded/decoded using this value, schema parsers MUST
defaultContentType: application/json
```
-
-
-
-
-
####
Channels Object
An object containing all the [Channel Object](#channelObject) definitions the [Application](#definitionsApplication) MUST use during runtime.
@@ -557,9 +558,6 @@ userSignedUp:
$ref: '#/components/messages/userSignedUp'
```
-
-
-
####
Channel Object
Describes a shared communication channel.
@@ -579,7 +577,6 @@ Field Name | Type | Description
externalDocs | [External Documentation Object](#externalDocumentationObject) \| [Reference Object](#referenceObject) | Additional external documentation for this channel.
bindings | [Channel Bindings Object](#channelBindingsObject) \| [Reference Object](#referenceObject) | A map where the keys describe the name of the protocol and the values describe protocol-specific definitions for the channel.
-
This object MAY be extended with [Specification Extensions](#specificationExtensions).
##### Channel Object Example
@@ -653,20 +650,12 @@ externalDocs:
url: 'https://example.com'
```
-
-
-
-
####
Channel Address Expressions
Channel addresses MAY contain expressions that can be used to define dynamic values.
Expressions MUST be composed by a name enclosed in curly braces (`{` and `}`). E.g., `{userId}`.
-
-
-
-
####
Messages Object
Describes a map of messages included in a channel.
@@ -697,8 +686,6 @@ userCompletedOrder:
$ref: '#/components/messages/userCompletedOrder'
```
-
-
####
Operations Object
Holds a dictionary with all the [operations](#operationObject) this application MUST implement.
@@ -759,7 +746,6 @@ onUserSignUp:
- $ref: '#/components/operationTraits/kafka'
```
-
####
Operation Object
Describes a specific operation.
@@ -863,12 +849,9 @@ reply:
- $ref: '#/components/messages/userSignedUpReply'
```
-
-
-
####
Operation Trait Object
-Describes a trait that MAY be applied to an [Operation Object](#operationObject). This object MAY contain any property from the [Operation Object](#operationObject), except the `action`, `channel` and `traits` ones.
+Describes a trait that MAY be applied to an [Operation Object](#operationObject). This object MAY contain any property from the [Operation Object](#operationObject), except the `action`, `channel`, `messages` and `traits` ones.
If you're looking to apply traits to a message, see the [Message Trait Object](#messageTraitObject).
@@ -904,9 +887,6 @@ bindings:
ack: false
```
-
-
-
####
Operation Reply Object
Describes the reply part that MAY be applied to an Operation Object. If an operation implements the request/reply pattern, the reply object represents the response message.
@@ -923,11 +903,10 @@ This object MAY be extended with [Specification Extensions](#specificationExtens
####
Operation Reply Address Object
-An object that specifies where an operation has to send the reply.
+An object that specifies where an operation has to send the reply.
For specifying and computing the location of a reply address, a [runtime expression](#runtimeExpression) is used.
-
##### Fixed Fields
Field Name | Type | Description
@@ -951,7 +930,6 @@ description: Consumer Inbox
location: $message.header#/replyTo
```
-
####
Parameters Object
Describes a map of parameters included in a channel address.
@@ -984,10 +962,6 @@ parameters:
description: Id of the user.
```
-
-
-
-
####
Parameter Object
Describes a parameter included in a channel address.
@@ -1026,9 +1000,6 @@ parameters:
location: $message.payload#/user/id
```
-
-
-
####
Server Bindings Object
Map describing protocol-specific definitions for a server.
@@ -1059,8 +1030,6 @@ Field Name | Type | Description
This object MAY be extended with [Specification Extensions](#specificationExtensions).
-
-
####
Channel Bindings Object
Map describing protocol-specific definitions for a channel.
@@ -1091,8 +1060,6 @@ Field Name | Type | Description
This object MAY be extended with [Specification Extensions](#specificationExtensions).
-
-
####
Operation Bindings Object
Map describing protocol-specific definitions for an operation.
@@ -1123,9 +1090,6 @@ Field Name | Type | Description
This object MAY be extended with [Specification Extensions](#specificationExtensions).
-
-
-
####
Message Bindings Object
Map describing protocol-specific definitions for a message.
@@ -1156,12 +1120,6 @@ Field Name | Type | Description
This object MAY be extended with [Specification Extensions](#specificationExtensions).
-
-
-
-
-
-
####
Message Object
Describes a message received on a given channel and operation.
@@ -1171,7 +1129,7 @@ Describes a message received on a given channel and operation.
Field Name | Type | Description
---|:---:|---
headers | [Multi Format Schema Object](#multiFormatSchemaObject) | [Schema Object](#schemaObject) | [Reference Object](#referenceObject) | Schema definition of the application headers. Schema MUST be a map of key-value pairs. It **MUST NOT** define the protocol headers. If this is a [Schema Object](#schemaObject), then the `schemaFormat` will be assumed to be "application/vnd.aai.asyncapi+json;version=`asyncapi`" where the version is equal to the [AsyncAPI Version String](#A2SVersionString).
-
payload | [Multi Format Schema Object](#multiFormatSchemaObject) | [Schema Object](#schemaObject) | [Reference Object](#referenceObject) | Definition of the message payload. If this is a [Schema Object](#schemaObject), then the `schemaFormat` will be assumed to be "application/vnd.aai.asyncapi+json;version=`asyncapi`" where the version is equal to the [AsyncAPI Version String](#A2SVersionString).
+
payload | [Multi Format Schema Object](#multiFormatSchemaObject) | [Schema Object](#schemaObject) | [Reference Object](#referenceObject) | Definition of the message payload. If this is a [Schema Object](#schemaObject), then the `schemaFormat` will be assumed to be "application/vnd.aai.asyncapi+json;version=`asyncapi`" where the version is equal to the [AsyncAPI Version String](#A2SVersionString).
correlationId | [Correlation ID Object](#correlationIdObject) | [Reference Object](#referenceObject) | Definition of the correlation ID used for message tracing or matching.
contentType | `string` | The content type to use when encoding/decoding a message's payload. The value MUST be a specific media type (e.g. `application/json`). When omitted, the value MUST be the one specified on the [defaultContentType](#defaultContentTypeString) field.
name | `string` | A machine-friendly name for the message.
@@ -1333,12 +1291,6 @@ payload:
$ref: 'path/to/user-create.avsc/#UserCreate'
```
-
-
-
-
-
-
####
Message Trait Object
Describes a trait that MAY be applied to a [Message Object](#messageObject). This object MAY contain any property from the [Message Object](#messageObject), except `payload` and `traits`.
@@ -1377,13 +1329,13 @@ contentType: application/json
####
Message Example Object
-Message Example Object represents an example of a [Message Object](#messageObject) and MUST contain either **headers** and/or **payload** fields.
+Message Example Object represents an example of a [Message Object](#messageObject) and MUST contain either **headers** and/or **payload** fields.
##### Fixed Fields
Field Name | Type | Description
---|:---:|---
-
headers | `Map[string, any]` | The value of this field MUST validate against the [Message Object's headers](#messageObjectHeaders) field.
+
headers | `Map[string, any]` | The value of this field MUST validate against the [Message Object's headers](#messageObjectHeaders) field.
payload | `Map[string, any]` | The value of this field MUST validate against the [Message Object's payload](#messageObjectPayload) field.
name | `string` | A machine-friendly name.
summary | `string` | A short summary of what the example is about.
@@ -1433,6 +1385,7 @@ A Tags object is a list of [Tag Objects](#tagObject). An [Tag Object](#tagObject
Allows adding meta data to a single tag.
##### Fixed Fields
+
Field Name | Type | Description
---|:---:|---
name | `string` | **REQUIRED.** The name of the tag.
@@ -1445,8 +1398,8 @@ This object MAY be extended with [Specification Extensions](#specificationExtens
```json
{
- "name": "user",
- "description": "User-related messages"
+ "name": "user",
+ "description": "User-related messages"
}
```
@@ -1455,12 +1408,6 @@ name: user
description: User-related messages
```
-
-
-
-
-
-
####
External Documentation Object
Allows referencing an external resource for extended documentation.
@@ -1488,7 +1435,6 @@ description: Find more info here
url: https://example.com
```
-
####
Reference Object
A simple object to allow referencing other components in the specification, internally and externally.
@@ -1498,6 +1444,7 @@ The Reference Object is defined by [JSON Reference](https://tools.ietf.org/html/
For this specification, reference resolution is done as defined by the JSON Reference specification and not by the JSON Schema specification.
##### Fixed Fields
+
Field Name | Type | Description
---|:---:|---
$ref | `string` | **REQUIRED.** The reference string.
@@ -1524,14 +1471,14 @@ All objects defined within the components object will have no effect on the API
##### Fixed Fields
Field Name | Type | Description
----|:---|---
+---|:---|---
schemas | Map[`string`, [Multi Format Schema Object](#multiFormatSchemaObject) \| [Schema Object](#schemaObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Schema Object](#schemaObject). If this is a [Schema Object](#schemaObject), then the `schemaFormat` will be assumed to be "application/vnd.aai.asyncapi+json;version=`asyncapi`" where the version is equal to the [AsyncAPI Version String](#A2SVersionString).
servers | Map[`string`, [Server Object](#serverObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Server Objects](#serverObject).
channels | Map[`string`, [Channel Object](#channelObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Channel Objects](#channelObject).
operations | Map[`string`, [Operation Object](#operationObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Operation Objects](#operationObject).
messages | Map[`string`, [Message Object](#messageObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Message Objects](#messageObject).
securitySchemes| Map[`string`, [Security Scheme Object](#securitySchemeObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Security Scheme Objects](#securitySchemeObject).
-
serverVariables | Map[`string`, [Server Variable Object](#serverVariableObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Server Variable Objects](#serverVariableObject).
+
serverVariables | Map[`string`, [Server Variable Object](#serverVariableObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Server Variable Objects](#serverVariableObject).
parameters | Map[`string`, [Parameter Object](#parameterObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Parameter Objects](#parameterObject).
correlationIds | Map[`string`, [Correlation ID Object](#correlationIdObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Correlation ID Objects](#correlationIdObject).
replies | Map[`string`, [Operation Reply Object](#operationReplyObject) \| [Reference Object](#referenceObject)] | An object to hold reusable [Operation Reply Objects](#operationReplyObject).
@@ -1551,7 +1498,7 @@ All the fixed fields declared above are objects that MUST use keys that match th
Field Name Examples:
-```
+```text
User
User_1
User_Name
@@ -1800,17 +1747,39 @@ The following table contains a set of values that every implementation MUST supp
Name | Allowed values | Notes
---|:---:|---
[AsyncAPI 3.0.0 Schema Object](#schemaObject) | `application/vnd.aai.asyncapi;version=3.0.0`, `application/vnd.aai.asyncapi+json;version=3.0.0`, `application/vnd.aai.asyncapi+yaml;version=3.0.0` | This is the default when a `schemaFormat` is not provided.
-[JSON Schema Draft 07](https://json-schema.org/specification-links.html#draft-7) | `application/schema+json;version=draft-07`, `application/schema+yaml;version=draft-07` |
+[JSON Schema Draft 07](https://json-schema.org/specification-links.html#draft-7) | `application/schema+json;version=draft-07`, `application/schema+yaml;version=draft-07` |
The following table contains a set of values that every implementation is RECOMMENDED to support.
Name | Allowed values | Notes
---|:---:|---
[Avro 1.9.0 schema](https://avro.apache.org/docs/1.9.0/spec.html#schemas) | `application/vnd.apache.avro;version=1.9.0`, `application/vnd.apache.avro+json;version=1.9.0`, `application/vnd.apache.avro+yaml;version=1.9.0` |
-[OpenAPI 3.0.0 Schema Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) | `application/vnd.oai.openapi;version=3.0.0`, `application/vnd.oai.openapi+json;version=3.0.0`, `application/vnd.oai.openapi+yaml;version=3.0.0` |
+[OpenAPI 3.0.0 Schema Object](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/3.0.0.md#schemaObject) | `application/vnd.oai.openapi;version=3.0.0`, `application/vnd.oai.openapi+json;version=3.0.0`, `application/vnd.oai.openapi+yaml;version=3.0.0` |
[RAML 1.0 data type](https://github.com/raml-org/raml-spec/blob/master/versions/raml-10/raml-10.md/) | `application/raml+yaml;version=1.0` |
-[Protocol Buffers](https://protobuf.dev/) | `application/vnd.google.protobuf;version=2`, `application/vnd.google.protobuf;version=3` |
+[Protocol Buffers](https://protobuf.dev/) | `application/vnd.google.protobuf;version=2`, `application/vnd.google.protobuf;version=3` |
+
+##### Multi Format Schema Object Examples
+###### Multi Format Schema Object Example with Avro
+
+```yaml
+channels:
+ example:
+ messages:
+ myMessage:
+ payload:
+ schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
+ schema:
+ type: record
+ name: User
+ namespace: com.company
+ doc: User information
+ fields:
+ - name: displayName
+ type: string
+ - name: age
+ type: int
+```
####
Schema Object
@@ -1818,7 +1787,7 @@ The Schema Object allows the definition of input and output data types.
These types can be objects, but also primitives and arrays. This object is a superset of the [JSON Schema Specification Draft 07](https://json-schema.org/). The empty schema (which allows any instance to validate) MAY be represented by the `boolean` value `true` and a schema which allows no instance to validate MAY be represented by the `boolean` value `false`.
Further information about the properties can be found in [JSON Schema Core](https://tools.ietf.org/html/draft-handrews-json-schema-01) and [JSON Schema Validation](https://tools.ietf.org/html/draft-handrews-json-schema-validation-01).
-Unless stated otherwise, the property definitions follow the JSON Schema specification as referenced here.
+Unless stated otherwise, the property definitions follow the JSON Schema specification as referenced here. For other formats (e.g., Avro, RAML, etc) see [Multi Format Schema Object](#multiFormatSchemaObject).
##### Properties
@@ -1869,6 +1838,7 @@ Alternatively, any time a Schema Object can be used, a [Reference Object](#refer
In addition to the JSON Schema fields, the following AsyncAPI vocabulary fields MAY be used for further schema documentation:
##### Fixed Fields
+
Field Name | Type | Description
---|:---:|---
discriminator | `string` | Adds support for polymorphism. The discriminator is the schema property name that is used to differentiate between other schema that inherit this schema. The property name used MUST be defined at this schema and it MUST be in the `required` property list. When used, the value MUST be the name of this schema or any schema that inherits it. See [Composition and Inheritance](#schemaComposition) for more details.
@@ -1880,7 +1850,7 @@ This object MAY be extended with [Specification Extensions](#specificationExtens
######
Composition and Inheritance (Polymorphism)
The AsyncAPI Specification allows combining and extending model definitions using the `allOf` property of JSON Schema, in effect offering model composition.
-`allOf` takes in an array of object definitions that are validated *independently* but together compose a single object.
+`allOf` takes in an array of object definitions that are validated _independently_ but together compose a single object.
While composition offers model extensibility, it does not imply a hierarchy between the models.
To support polymorphism, AsyncAPI Specification adds the support of the `discriminator` field.
@@ -1891,7 +1861,7 @@ There are two ways to define the value of a discriminator for an inheriting inst
- Use the schema's name.
- Override the schema's name by overriding the property with a new value. If exists, this takes precedence over the schema's name.
-As such, inline schema definitions, which do not have a given id, *cannot* be used in polymorphism.
+As such, inline schema definitions, which do not have a given id, _cannot_ be used in polymorphism.
##### Schema Object Examples
@@ -2276,25 +2246,22 @@ schemas:
- color
```
-
-
-
-
####
Security Scheme Object
Defines a security scheme that can be used by the operations. Supported schemes are:
-* User/Password.
-* API key (either as user or as password).
-* X.509 certificate.
-* End-to-end encryption (either symmetric or asymmetric).
-* HTTP authentication.
-* HTTP API key.
-* OAuth2's common flows (Implicit, Resource Owner Protected Credentials, Client Credentials and Authorization Code) as defined in [RFC6749](https://tools.ietf.org/html/rfc6749).
-* [OpenID Connect Discovery](https://tools.ietf.org/html/draft-ietf-oauth-discovery-06).
-* SASL (Simple Authentication and Security Layer) as defined in [RFC4422](https://tools.ietf.org/html/rfc4422).
+- User/Password.
+- API key (either as user or as password).
+- X.509 certificate.
+- End-to-end encryption (either symmetric or asymmetric).
+- HTTP authentication.
+- HTTP API key.
+- OAuth2's common flows (Implicit, Resource Owner Protected Credentials, Client Credentials and Authorization Code) as defined in [RFC6749](https://tools.ietf.org/html/rfc6749).
+- [OpenID Connect Discovery](https://tools.ietf.org/html/draft-ietf-oauth-discovery-06).
+- SASL (Simple Authentication and Security Layer) as defined in [RFC4422](https://tools.ietf.org/html/rfc4422).
##### Fixed Fields
+
Field Name | Type | Applies To | Description
---|:---:|---|---
type | `string` | Any | **REQUIRED**. The type of the security scheme. Valid values are `"userPassword"`, `"apiKey"`, `"X509"`, `"symmetricEncryption"`, `"asymmetricEncryption"`, `"httpApiKey"`, `"http"`, `"oauth2"`, `"openIdConnect"`, `"plain"`, `"scramSha256"`, `"scramSha512"`, and `"gssapi"`.
@@ -2456,6 +2423,7 @@ type: scramSha512
Allows configuration of the supported OAuth Flows.
##### Fixed Fields
+
Field Name | Type | Description
---|:---:|---
implicit| [OAuth Flow Object](#oauthFlowObject) | Configuration for the OAuth Implicit flow.
@@ -2470,6 +2438,7 @@ This object MAY be extended with [Specification Extensions](#specificationExtens
Configuration details for a supported OAuth Flow
##### Fixed Fields
+
Field Name | Type | Applies To | Description
---|:---:|---|---
authorizationUrl | `string` | `oauth2` (`"implicit"`, `"authorizationCode"`) | **REQUIRED**. The authorization URL to be used for this flow. This MUST be in the form of an absolute URL.
@@ -2500,15 +2469,13 @@ availableScopes:
read:pets: read your pets
```
-
-
###
Correlation ID Object
-An object that specifies an identifier at design time that can used for message tracing and correlation.
+An object that specifies an identifier at design time that can used for message tracing and correlation.
For specifying and computing the location of a Correlation ID, a [runtime expression](#runtimeExpression) is used.
-##### Fixed Fields
+#### Fixed Fields
Field Name | Type | Description
---|:---|---
@@ -2538,7 +2505,7 @@ This mechanism is used by [Correlation ID Object](#correlationIdObject) and [Ope
The runtime expression is defined by the following [ABNF](https://tools.ietf.org/html/rfc5234) syntax:
-```
+```text
expression = ( "$message" "." source )
source = ( header-reference | payload-reference )
header-reference = "header" ["#" fragment]
@@ -2548,7 +2515,7 @@ The runtime expression is defined by the following [ABNF](https://tools.ietf.org
The table below provides examples of runtime expressions and examples of their use in a value:
-#####
Examples
+####
Examples
Source Location | Example expression | Notes
---|:---|:---|
@@ -2591,7 +2558,7 @@ The extensions properties are implemented as patterned fields that are always pr
Field Pattern | Type | Description
---|:---:|---
-
`^x-[\w\d\-\_]+$` | Any | Allows extensions to the AsyncAPI Schema. The field name MUST begin with `x-`, for example, `x-internal-id`. The value can be `null`, a primitive, an array or an object. Can have any valid JSON format value.
+
`^x-[\w\d\.\x2d_]+$` | Any | Allows extensions to the AsyncAPI Schema. The field name MUST begin with `x-`, for example, `x-internal-id`. The value can be `null`, a primitive, an array or an object. Can have any valid JSON format value.
The extensions may or may not be supported by the available tooling, but those may be extended as well to add requested support (if tools are internal or open-sourced).
@@ -2606,7 +2573,6 @@ Tools that do not recognize a specific `format` MAY default back to the `type` a
The formats defined by the AsyncAPI Specification are:
-
Common Name | `type` | [`format`](#dataTypeFormat) | Comments
----------- | ------ | -------- | --------
integer | `integer` | `int32` | signed 32 bits
diff --git a/pages/docs/tools/cli/usage.md b/pages/docs/tools/cli/usage.md
index 2da2d6edd422..90967e59f25c 100644
--- a/pages/docs/tools/cli/usage.md
+++ b/pages/docs/tools/cli/usage.md
@@ -29,7 +29,7 @@ $ npm install -g @asyncapi/cli
$ asyncapi COMMAND
running command...
$ asyncapi (--version)
-@asyncapi/cli/1.4.1 linux-x64 node-v18.19.0
+@asyncapi/cli/1.5.11 linux-x64 node-v18.19.1
$ asyncapi --help [COMMAND]
USAGE
$ asyncapi COMMAND
@@ -93,7 +93,7 @@ EXAMPLES
$ asyncapi bundle ./asyncapi.yaml ./features.yaml --base ./asyncapi.yaml --reference-into-components
```
-_See code: [src/commands/bundle.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/bundle.ts)_
+_See code: [src/commands/bundle.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/bundle.ts)_
## `asyncapi config`
@@ -107,7 +107,7 @@ DESCRIPTION
CLI config settings
```
-_See code: [src/commands/config/index.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/index.ts)_
+_See code: [src/commands/config/index.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/index.ts)_
## `asyncapi config context`
@@ -121,7 +121,7 @@ DESCRIPTION
Manage short aliases for full paths to AsyncAPI documents
```
-_See code: [src/commands/config/context/index.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/context/index.ts)_
+_See code: [src/commands/config/context/index.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/context/index.ts)_
## `asyncapi config context add CONTEXT-NAME SPEC-FILE-PATH`
@@ -143,7 +143,7 @@ DESCRIPTION
Add a context to the store
```
-_See code: [src/commands/config/context/add.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/context/add.ts)_
+_See code: [src/commands/config/context/add.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/context/add.ts)_
## `asyncapi config context current`
@@ -160,7 +160,7 @@ DESCRIPTION
Shows the current context that is being used
```
-_See code: [src/commands/config/context/current.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/context/current.ts)_
+_See code: [src/commands/config/context/current.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/context/current.ts)_
## `asyncapi config context edit CONTEXT-NAME NEW-SPEC-FILE-PATH`
@@ -181,7 +181,7 @@ DESCRIPTION
Edit a context in the store
```
-_See code: [src/commands/config/context/edit.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/context/edit.ts)_
+_See code: [src/commands/config/context/edit.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/context/edit.ts)_
## `asyncapi config context init [CONTEXT-FILE-PATH]`
@@ -204,7 +204,7 @@ DESCRIPTION
Initialize context
```
-_See code: [src/commands/config/context/init.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/context/init.ts)_
+_See code: [src/commands/config/context/init.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/context/init.ts)_
## `asyncapi config context list`
@@ -221,7 +221,7 @@ DESCRIPTION
List all the stored contexts in the store
```
-_See code: [src/commands/config/context/list.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/context/list.ts)_
+_See code: [src/commands/config/context/list.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/context/list.ts)_
## `asyncapi config context remove CONTEXT-NAME`
@@ -241,7 +241,7 @@ DESCRIPTION
Delete a context from the store
```
-_See code: [src/commands/config/context/remove.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/context/remove.ts)_
+_See code: [src/commands/config/context/remove.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/context/remove.ts)_
## `asyncapi config context use CONTEXT-NAME`
@@ -261,7 +261,7 @@ DESCRIPTION
Set a context as current
```
-_See code: [src/commands/config/context/use.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/context/use.ts)_
+_See code: [src/commands/config/context/use.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/context/use.ts)_
## `asyncapi config versions`
@@ -278,7 +278,7 @@ DESCRIPTION
Show versions of AsyncAPI tools used
```
-_See code: [src/commands/config/versions.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/config/versions.ts)_
+_See code: [src/commands/config/versions.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/config/versions.ts)_
## `asyncapi convert [SPEC-FILE]`
@@ -300,7 +300,7 @@ DESCRIPTION
Convert asyncapi documents older to newer versions
```
-_See code: [src/commands/convert.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/convert.ts)_
+_See code: [src/commands/convert.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/convert.ts)_
## `asyncapi diff OLD NEW`
@@ -355,7 +355,7 @@ DESCRIPTION
Find diff between two asyncapi files
```
-_See code: [src/commands/diff.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/diff.ts)_
+_See code: [src/commands/diff.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/diff.ts)_
## `asyncapi generate`
@@ -369,7 +369,7 @@ DESCRIPTION
Generate typed models or other things like clients, applications or docs using AsyncAPI Generator templates.
```
-_See code: [src/commands/generate/index.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/generate/index.ts)_
+_See code: [src/commands/generate/index.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/generate/index.ts)_
## `asyncapi generate fromTemplate ASYNCAPI TEMPLATE`
@@ -406,7 +406,7 @@ EXAMPLES
$ asyncapi generate fromTemplate asyncapi.yaml @asyncapi/html-template --param version=1.0.0 singleFile=true --output ./docs --force-write
```
-_See code: [src/commands/generate/fromTemplate.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/generate/fromTemplate.ts)_
+_See code: [src/commands/generate/fromTemplate.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/generate/fromTemplate.ts)_
## `asyncapi generate models LANGUAGE FILE`
@@ -486,7 +486,7 @@ DESCRIPTION
Generates typed models
```
-_See code: [src/commands/generate/models.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/generate/models.ts)_
+_See code: [src/commands/generate/models.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/generate/models.ts)_
## `asyncapi new`
@@ -500,7 +500,6 @@ FLAGS
-e, --example=
name of the example to use. Available examples are:
- simple-asyncapi.yml
- - adeo-kafka-request-reply-asyncapi.yml
- anyof-asyncapi.yml
- application-headers-asyncapi.yml
- correlation-id-asyncapi.yml
@@ -544,7 +543,7 @@ EXAMPLES
$ asyncapi new --file-name=my-asyncapi.yml --example=default-example.yml --no-tty - create a new file with a specific name, using one of the examples and without interactive mode
```
-_See code: [src/commands/new/index.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/new/index.ts)_
+_See code: [src/commands/new/index.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/new/index.ts)_
## `asyncapi new file`
@@ -558,7 +557,6 @@ FLAGS
-e, --example=
name of the example to use. Available examples are:
- simple-asyncapi.yml
- - adeo-kafka-request-reply-asyncapi.yml
- anyof-asyncapi.yml
- application-headers-asyncapi.yml
- correlation-id-asyncapi.yml
@@ -602,7 +600,7 @@ EXAMPLES
$ asyncapi new --file-name=my-asyncapi.yml --example=default-example.yml --no-tty - create a new file with a specific name, using one of the examples and without interactive mode
```
-_See code: [src/commands/new/file.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/new/file.ts)_
+_See code: [src/commands/new/file.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/new/file.ts)_
## `asyncapi new glee`
@@ -610,18 +608,21 @@ Creates a new Glee project
```
USAGE
- $ asyncapi new glee [-h] [-n ] [-t ]
+ $ asyncapi new glee [-h] [-n ] [-t ] [-f ] [--force-write]
FLAGS
+ -f, --file= The path to the AsyncAPI file for generating a Glee project.
-h, --help Show CLI help.
- -n, --name= [default: project] name of the project
- -t, --template= [default: default] name of the template
+ -n, --name= [default: project] Name of the Project
+ -t, --template= [default: default] Name of the Template
+ --force-write Force writing of the generated files to given directory even if it is a git repo with unstaged
+ files or not empty dir (defaults to false)
DESCRIPTION
Creates a new Glee project
```
-_See code: [src/commands/new/glee.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/new/glee.ts)_
+_See code: [src/commands/new/glee.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/new/glee.ts)_
## `asyncapi new project`
@@ -629,18 +630,21 @@ Creates a new Glee project
```
USAGE
- $ asyncapi new project [-h] [-n ] [-t ]
+ $ asyncapi new project [-h] [-n ] [-t ] [-f ] [--force-write]
FLAGS
+ -f, --file= The path to the AsyncAPI file for generating a Glee project.
-h, --help Show CLI help.
- -n, --name= [default: project] name of the project
- -t, --template= [default: default] name of the template
+ -n, --name= [default: project] Name of the Project
+ -t, --template= [default: default] Name of the Template
+ --force-write Force writing of the generated files to given directory even if it is a git repo with unstaged
+ files or not empty dir (defaults to false)
DESCRIPTION
Creates a new Glee project
```
-_See code: [src/commands/new/project.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/new/project.ts)_
+_See code: [src/commands/new/project.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/new/project.ts)_
## `asyncapi optimize [SPEC-FILE]`
@@ -676,7 +680,7 @@ EXAMPLES
$ asyncapi optimize ./asyncapi.yaml --optimization=remove-components,reuse-components,move-to-components --output=terminal --no-tty
```
-_See code: [src/commands/optimize.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/optimize.ts)_
+_See code: [src/commands/optimize.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/optimize.ts)_
## `asyncapi start`
@@ -690,7 +694,7 @@ DESCRIPTION
Start asyncapi studio
```
-_See code: [src/commands/start/index.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/start/index.ts)_
+_See code: [src/commands/start/index.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/start/index.ts)_
## `asyncapi start studio`
@@ -709,7 +713,7 @@ DESCRIPTION
starts a new local instance of Studio
```
-_See code: [src/commands/start/studio.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/start/studio.ts)_
+_See code: [src/commands/start/studio.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/start/studio.ts)_
## `asyncapi validate [SPEC-FILE]`
@@ -736,5 +740,5 @@ DESCRIPTION
validate asyncapi file
```
-_See code: [src/commands/validate.ts](https://github.com/asyncapi/cli/blob/v1.4.1/src/commands/validate.ts)_
+_See code: [src/commands/validate.ts](https://github.com/asyncapi/cli/blob/v1.5.11/src/commands/validate.ts)_
diff --git a/pages/docs/tools/generator/generator-template.md b/pages/docs/tools/generator/generator-template.md
index c6bc65c286aa..da10e6f6af30 100644
--- a/pages/docs/tools/generator/generator-template.md
+++ b/pages/docs/tools/generator/generator-template.md
@@ -572,4 +572,4 @@ Great job completing this tutorial! You have learnt how to use an AsyncAPI file
If you want to tinker with a completed template and see what it would look like in production, check out the [Paho-MQTT template](https://github.com/derberg/python-mqtt-client-template/tree/v1.0.0). You can also check out the accompanying [article about creating MQTT client code](https://www.brainfart.dev/blog/asyncapi-codegen-python).
-You can also check out the [MQTT beginners guide]((https://medium.com/python-point/mqtt-basics-with-python-examples-7c758e605d4)) tutorial to learn more about asynchronous messaging using MQTT.
+You can also check out the [MQTT beginners guide](https://medium.com/python-point/mqtt-basics-with-python-examples-7c758e605d4) tutorial to learn more about asynchronous messaging using MQTT.
diff --git a/pages/docs/tutorials/kafka/_section.md b/pages/docs/tutorials/kafka/_section.md
new file mode 100644
index 000000000000..d96cc1127f84
--- /dev/null
+++ b/pages/docs/tutorials/kafka/_section.md
@@ -0,0 +1,4 @@
+---
+title: 'Kafka'
+weight: 220
+---
\ No newline at end of file
diff --git a/pages/docs/tutorials/kafka/configure-kafka-avro.md b/pages/docs/tutorials/kafka/configure-kafka-avro.md
new file mode 100644
index 000000000000..40a1cf1926a8
--- /dev/null
+++ b/pages/docs/tutorials/kafka/configure-kafka-avro.md
@@ -0,0 +1,162 @@
+---
+title: Describe Kafka message payload using Avro Schema
+description: Explore configuring an AsyncAPI document for Kafka messages with Avro Schema.
+weight: 230
+---
+
+## Introduction
+
+The previous tutorial on [creating an AsyncAPI document for applications consuming from Kafka](/docs/tutorials/kafka) taught you about writing an AsyncAPI document for Kafka messages using the default schema. This tutorial will teach you to write the same document using Avro Schema.
+
+While AsyncAPI schema can be the default choice for describing payloads, many prefer using Avro Schemas to define messages in Kafka. This tutorial teaches you to modify your existing AsyncAPI schema to add Avro schema into your document in both YAML and JSON formats.
+
+## Background context
+
+AsyncAPI is a specification for describing Event-Driven Architectures (EDAs) in a machine-readable format. AsyncAPI schema outlines the format and content specifications that enable a consistent representation of agreements for communication between services in an Event-Driven Architecture.
+
+[Avro](https://avro.apache.org/) is a sophisticated tool in Apache Kafka that handles data communication efficiently. It provides a standardized method for organizing and transmitting data, ensuring that different parts of the system can understand each other effectively. With Avro, there's a common language for messages, promoting compatibility and smooth operation between various components. It's like having a shared rulebook that helps different system parts communicate and exchange information seamlessly.
+
+## Define message payload with Avro Schema directly in AsyncAPI document
+
+Defining message schema with the default schema is already covered in the [previous Kafka tutorial](/docs/tutorials/Kafka). The default choice was the AsyncAPI schema, a JSON Schema superset. Here's an example of what the AsyncAPI schema looks like:
+
+```
+messages:
+ userSignedUp:
+ payload:
+ type: object
+ properties:
+ userId:
+ type: integer
+ description: This property describes the ID of the user
+ userEmail:
+ type: string
+ description: This property describes the email of the user
+```
+
+Now it's time to shift your focus to defining messages using Avro Schemas directly within your document.
+
+```
+messages:
+ userSignedUp:
+ payload:
+ schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
+ schema:
+ type: record
+ name: UserSignedUp
+ namespace: com.company
+ doc: User sign-up information
+ fields:
+ - name: userId
+ type: int
+ - name: userEmail
+ type: string
+```
+
+In the above code snippet:
+- The `userSignedUp` message is defined with Avro Schema, using the specified `schemaFormat` and the `schema`.
+- Use the `schemaFormat` to indicate that you're using Avro and specify the version of Avro Schema by using a MIME type.
+- The `schema` includes a `record` named `UserSignedUp` within the `com.company` namespace. It also describes two fields, `userId` and `userEmail,` defining their data types as `int` and `string`, respectively.
+
+Now let's combine the above Avro Schema with the AsyncAPI document that you created in the previous tutorial. Check out below what an AsyncAPI document fully equipped with Avro Schema looks like!
+
+```
+asyncapi: 3.0.0
+info:
+ title: User Signup API
+ version: 1.0.0
+ description: The API notifies you whenever a new user signs up in the application.
+servers:
+ kafkaServer:
+ host: test.mykafkacluster.org:8092
+ description: Kafka Server
+ protocol: kafka
+operations:
+ onUserSignedUp:
+ action: receive
+ channel:
+ $ref: '#/channels/userSignedUp'
+channels:
+ userSignedUp:
+ description: This channel contains a message per each user who signs up in our application.
+ address: user_signedup
+ messages:
+ userSignedUp:
+ $ref: '#/components/messages/userSignedUp'
+components:
+ messages:
+ userSignedUp:
+ payload:
+ schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
+ schema:
+ type: record
+ name: UserSignedUp
+ namespace: com.company
+ doc: User sign-up information
+ fields:
+ - name: userId
+ type: int
+ - name: userEmail
+ type: string
+```
+
+## Reusing existing Avro Schemas
+
+Occasionally, you might find yourself with an existing set of Avro Schemas. In such cases, instead of repeatedly defining these schemas in your AsyncAPI document, integrate them seamlessly by calling out existing files.
+
+Assume you have a file named `userSchema.json` that encapsulates the Avro Schema that resembles the following:
+
+```
+// userSchema.json
+{
+ "type": "record",
+ "name": "UserSignedUp",
+ "namespace": "com.company",
+ "doc": "User sign-up information",
+ "fields": [
+ { "name": "userId", "type": "int" },
+ { "name": "userEmail", "type": "string" }
+ ]
+}
+```
+
+To seamlessly incorporate this existing Avro schema into your AsyncAPI document, you can use the `$ref` property to reference the path to the JSON file. This way, your AsyncAPI document will incorporate the Avro Schema from the external JSON file, ensuring consistency and interoperability in your Kafka ecosystem.
+
+```
+asyncapi: 3.0.0
+info:
+ title: User Signup API
+ version: 1.0.0
+ description: The API notifies you whenever a new user signs up in the application.
+servers:
+ kafkaServer:
+ host: test.mykafkacluster.org:8092
+ description: Kafka Server
+ protocol: kafka
+operations:
+ onUserSignedUp:
+ action: receive
+ channel:
+ $ref: '#/channels/userSignedUp'
+channels:
+ userSignedUp:
+ description: This channel contains a message per each user who signs up in our application.
+ address: user_signedup
+ messages:
+ userSignedUp:
+ $ref: '#/components/messages/userSignedUp'
+components:
+ messages:
+ userSignedUp:
+ payload:
+ schemaFormat: 'application/vnd.apache.avro;version=1.9.0'
+ schema:
+ $ref: './userSchema.json'
+```
+
+## Summary
+
+In this tutorial, you smoothly updated from the default schema to utilize the capabilities of Avro Schema. The use of Avro Schema with AsyncAPI ensures improved communication in event-driven systems. Now, you can further experiment by incorporating your business logic and experimenting with more advanced capabilities.
+
+## Next Steps
+Now that you know how to write an AsyncAPI document using Avro Schemas, let's learn how to use [Schema Registry with AsyncAPI](/docs/tutorials/kafka/managing-schemas-using-schema-registry).
diff --git a/pages/docs/tutorials/kafka/index.md b/pages/docs/tutorials/kafka/index.md
new file mode 100644
index 000000000000..a56b8062e23c
--- /dev/null
+++ b/pages/docs/tutorials/kafka/index.md
@@ -0,0 +1,200 @@
+---
+title: Create AsyncAPI document for applications consuming from Kafka
+description: A tutorial teaching how to configure an AsyncAPI document for Kafka messages.
+weight: 220
+---
+
+## Introduction
+
+In this tutorial, you will create a schema document for Kafka Messages using AsyncAPI. You will also learn about Event-Driven Architecture, the pub/sub model, and brokers concerning Kafka.
+
+Suppose you have a service publishing data to a Kafka topic whenever a new user signs up on your application.
+
+You want to build a system that tracks users who have signed up for your application. As such, your application will have the following flow:
+
+```mermaid
+sequenceDiagram
+ participant Your Application (Consumer)
+ participant Kafka
+ participant Service (Producer)
+ participant User
+ Your Application (Consumer)->> Kafka: Subscribes to "userSignedUp" topic
+ User-->> Service (Producer): Signs Up
+ Service (Producer)->> Kafka: Publishes Events
+ Kafka->> Your Application (Consumer): Sends "user_signup" message
+```
+
+
+## Background context
+
+[Event-Driven Architecture (EDA)](/docs/tutorials/getting-started/event-driven-architectures) is a design pattern that revolves around the production, detection, and reaction to events over time. It consists of three main components: a message broker, event publishers, and subscribers, which together serve as the backbone for event exchange within different services.
+
+[Message brokers](/docs/tutorials/getting-started/event-driven-architectures#message-broker) facilitate asynchronous communications between services, meaning the sending service doesn't have to wait for the receiving service's response. Multiple services can talk to each other directly, even if they are written in different languages.
+
+A great example of such a message broker is Apache Kafka. [Apache Kafka](https://kafka.apache.org/) is a distributed event streaming platform thousands of companies use for their event-driven system. Here, a distributed event streaming platform is a system that operates on multiple nodes, providing high availability and fault tolerance.
+
+[Publisher/Subscriber (Pub/Sub)](/docs/tutorials/getting-started/event-driven-architectures#publishersubscriber) is a typical model in EDAs, providing flexible coupling between publishers and subscribers. In this model, those who `send` event notifications act as publishers, while those who `receive` the notifications act as the corresponding subscribers.
+
+## Create AsyncAPI document for Kafka messages
+
+In this section, you’ll create an AsyncAPI document to describe the `UserSignUp` API. The same document can be later used to generate code and documentation as per requirement.
+
+Let's begin by analyzing the document. As you progress in the tutorial, we'll break down each segment, uncovering its purpose and functionality.
+
+```
+asyncapi: 3.0.0
+info:
+ title: User Signup API
+ version: 1.0.0
+ description: The API notifies you whenever a new user signs up in the application.
+
+servers:
+ centralKafkaServer:
+ host: central.mykafkacluster.org:8092
+ description: Kafka broker running in a central warehouse
+ protocol: kafka
+ westKafkaServer:
+ host: west.mykafkacluster.org:8092
+ description: Kafka broker running in the west warehouse
+ protocol: kafka
+ eastKafkaServer:
+ host: east.mykafkacluster.org:8092
+ description: Kafka broker running in the east warehouse
+ protocol: kafka
+
+operations:
+ onUserSignedUp:
+ action: receive
+ channel:
+ $ref: '#/channels/userSignedUp'
+
+channels:
+ userSignedUp:
+ description: This channel contains a message per each user who signs up in our application.
+ address: user_signedup
+ messages:
+ userSignedUp:
+ $ref: '#/components/messages/userSignedUp'
+
+components:
+ messages:
+ userSignedUp:
+ payload:
+ type: object
+ properties:
+ userId:
+ type: integer
+ description: This property describes the id of the user
+ userEmail:
+ type: string
+ description: This property describes the email of the user
+```
+
+Let's now break it down into pieces.
+
+### Define AsyncAPI version, API information, and server
+
+First, you must describe your application, including the AsyncAPI version, the info about the document, and the server your application is based on.
+
+```
+asyncapi: 3.0.0
+info:
+ title: User Signup API
+ version: 1.0.0
+ description: The API notifies you whenever a new user signs up in the application.
+servers:
+ centralKafkaServer:
+ host: central.mykafkacluster.org:8092
+ description: Kafka broker running in a central warehouse
+ protocol: kafka
+ westKafkaServer:
+ host: west.mykafkacluster.org:8092
+ description: Kafka broker running in the west warehouse
+ protocol: kafka
+ eastKafkaServer:
+ host: east.mykafkacluster.org:8092
+ description: Kafka broker running in the east warehouse
+ protocol: kafka
+```
+
+In the above snippet:
+
+- The `asyncapi` field indicates that you use AsyncAPI version 3.0.0.
+
+- The `info` field provides information about the API. Here the the APIs `title`, `version`, and `description` are being defined.
+
+- The `server` field specifies the details of the server, including the `host`, `description`, and the `protocol` that is being used (i.e., Kafka). This section allows you to define multiple clusters or servers, as shown in the provided code block.
+
+
+If an application has multiple servers hidden from the user behind a load balancer, then only the address of the load balancer must be included in the AsyncAPI document.
+
+
+### Define channels
+
+Next, let's move on to the `channels` section. The channel addresses are the topics in Kafka; they are the routes to which your API will send/receive messages.
+
+```
+channels:
+ userSignedUp:
+ description: This channel contains a message per each user who signs up in our application.
+ address: user_signedup
+ messages:
+ userSignedUp:
+ $ref: '#/components/messages/userSignedUp'
+```
+
+In the above code snippet:
+
+- The `userSignedUp` object inside `channels` describes the Kafka topic where the application will receive the information and the associated message definition.
+- The `address` field represents the actual name of the Kafka topic and the `messages` field describes the expected messages in that topic.
+
+### Define operations
+
+Now, let's move on to the `operations` section. The `operations` property is used to describe how your application interacts with the defined channels.
+
+```
+operations:
+ onUserSignedUp:
+ action: receive
+ channel:
+ $ref: '#/channels/userSignedUp'
+```
+
+In the above code snippet:
+
+- The `onUserSignedUp` object specifies the operation's nature, which occurs when the user signs up.
+- The `action` property indicates that the application will receive the information.
+- The `channel` property points to the channel where the operation occurs.
+
+### Define messages and schemas
+
+Finally, you'll define the messages and their payload. The payload defines how the event would look like when it's sent from the channel.
+
+```
+components:
+ messages:
+ userSignedUp:
+ payload:
+ type: object
+ properties:
+ userId:
+ type: integer
+ description: This property describes the ID of the user
+ userEmail:
+ type: string
+ description: This property describes the ID of the user
+```
+
+In the above code snippet:
+
+- The `userSignedUp` message is defined which describes the payload (content) of the message.
+
+- The `payload` property defines the message content. Your message payload should contain a `userId`, an integer, a `userEmail` property, and a string property.
+
+## Summary
+
+The ability to generate an AsyncAPI document for Kafka is now in your toolkit. You generated an AsyncAPI document that defines the structure of the Kafka messages in a machine-readable format, which makes it easier to maintain event-driven architecture. Try adding your business logic and playing around with it.
+
+## Next steps
+
+Now that you know how to write an AsyncAPI document for Kafka messages using the default schema, let's learn how to create an [AsyncAPI document using Avro Schema instead](/docs/tutorials/kafka/configure-kafka-avro).
diff --git a/pages/docs/tutorials/websocket/_section.md b/pages/docs/tutorials/websocket/_section.md
new file mode 100644
index 000000000000..f0967315b307
--- /dev/null
+++ b/pages/docs/tutorials/websocket/_section.md
@@ -0,0 +1,4 @@
+---
+title: 'WebSocket'
+weight: 200
+---
diff --git a/pages/docs/tutorials/websocket/index.md b/pages/docs/tutorials/websocket/index.md
new file mode 100644
index 000000000000..ca3ac0363bc3
--- /dev/null
+++ b/pages/docs/tutorials/websocket/index.md
@@ -0,0 +1,321 @@
+---
+title: Create an AsyncAPI document for a Slackbot with WebSocket
+description: In this tutorial, you'll learn how to create an AsyncAPI document designed for a Slack application that operates in Socket Mode using the WebSocket protocol.
+weight: 210
+---
+
+## Introduction
+In this tutorial, you will learn how to write an AsyncAPI document designed for a Slack application that operates in Socket Mode. The aim is to help you grasp a real-world application of AsyncAPI with the WebSocket protocol. You will learn how to write an AsyncAPI document for a consumer-only application receiving a stream of messages from a WebSocket server. You will also learn why the AsyncAPI bindings feature exists and how to use it.
+
+Consider a scenario where you are in charge of maintaining a highly active Slack workspace. You want an easy way to keep track of the popular messages across all channels, but doing this manually would be difficult. To simplify this process, you will build a Slackbot called `Heart-Counter` that actively monitors reactions added to a message and determines its popularity by counting the reactions of the “heart” emoji.
+
+Here’s a visual representation of how the `Heart-Counter` should work:
+
+```mermaid
+sequenceDiagram
+participant Heart-Counter
+participant Slack Server (Socket Mode)
+participant User
+
+
+Heart-Counter ->>Slack Server (Socket Mode): Connect
+Note right of Heart-Counter: Establish WebSocket connection
+
+
+Slack Server (Socket Mode)->> Heart-Counter : Handshake
+Note left of Slack Server (Socket Mode): Establish Socket Mode connection
+
+Slack Server (Socket Mode)->> Heart-Counter : Sends "hello" event
+Note left of Slack Server (Socket Mode): Confirms successful connection
+
+
+
+
+
+User-->>Slack Server (Socket Mode): Adds emoji to a message.
+
+
+Slack Server (Socket Mode)->>Heart-Counter: Sending "reaction_added" payload
+
+
+Note left of Heart-Counter: Event received
+```
+
+## Background context
+[WebSocket](https://en.wikipedia.org/wiki/WebSocket) is a communication protocol that enables simultaneous bidirectional data exchange between a client and a server over a single, long-lived connection. Unlike HTTP, which relies on the request-response model, WebSocket is ideal for scenarios where real-time, interactive, and low-latency communication is necessary.
+
+
+```mermaid
+sequenceDiagram
+Client -->> Server: Initiate WebSocket Connection
+Server -->> Client: Message 1
+Server -->> Client: Message 2
+Server -->> Client: Message 3
+Server -->> Client: Message 4
+```
+
+In Slack, WebSocket is employed as part of its [Socket Mode](https://api.slack.com/apis/connections/socket) feature to facilitate real-time notifications between Slack's servers and third-party applications or bots. The [Slack Event API](https://api.slack.com/apis/connections/events-api) is a tool that lets you receive real-time notifications of specific events in a Slack workspace such as messages, reactions, and user presence changes.
+
+
+## Define AsyncAPI version, API information, and server
+
+You start your AsyncAPI document by specifying the AsyncAPI version and essential information about your Slack application's API, which includes details such as the `title,` `version,` and `description.`
+
+The `servers` section allows you to define the protocol and specify information about the URLs your application will use, such as `host`, `pathname`, `protocol`, and `description`.
+
+
+The WebSocket URL is generated by invoking the apps.connections.open method from Slack’s API. You use the authentication tokens obtained during the configuration of your Slackbot to generate this URL.
+
+
+
+{`asyncapi: '3.0.0'
+info:
+ title: Create an AsyncAPI document for a Slackbot with WebSocket
+ version: '1.0.0'
+ description: |
+ The Heart-Counter manages popular messages in a Slack workspace by monitoring message reaction data
+servers:
+ production:
+ host: wss-primary.slack.com
+ pathname: /link
+ protocol: wss
+ description: Slack's server in Socket Mode for real-time communication `}
+
+
+## Define messages and schemas
+
+Your AsyncAPI document needs to be very clear on the type of event it is expected to receive. Here's where the `messages` component steps in. Using the `payload` property, you can specify what these events should look like, their structure, and what content they carry.
+
+The `payload` attribute specifies the name, format, and description of all the expected properties. `Heart-Counter` starts the popularity count of a message by validating if the `reaction` property set in the `reaction` schema definition corresponds to "heart".
+
+
+{`components:
+ messages:
+ reaction:
+ summary: Action triggered when the channel receives a new reaction-added event
+ payload:
+ $ref: '#/components/schemas/reaction'
+ hello:
+ summary: Action triggered when a successful WebSocket connection is established
+ payload:
+ $ref: '#/components/schemas/hello'
+ schemas:
+ hello:
+ type: object
+ properties:
+ type:
+ type: string
+ description: A hello string confirming WebSocket connection
+ connection_info:
+ type: object
+ properties:
+ app_id:
+ type: string
+ num_connections:
+ type: integer
+ debug_info:
+ type: object
+ properties:
+ host:
+ type: string
+ started:
+ type: string
+ build_number:
+ type: integer
+ approximate_connection_time:
+ type: integer
+ reaction:
+ type: object
+ properties:
+ user:
+ type: string
+ description: User ID who performed this event
+ reaction:
+ type: string
+ description: The only reaction that we need is a heart emoji
+ item_user:
+ type: string
+ description: User ID that created the original item that has been reacted to
+ item:
+ type: object
+ properties:
+ channel:
+ type: string
+ description: Channel information of original message
+ ts:
+ type: string
+ description: Timestamp information of original message
+ event_ts:
+ type: string
+ description: Reaction timestamp `}
+
+
+## Define channels and bindings
+
+The `channels` attribute defines a communication channel for the event. The `address` specifies where the channel is tuned in to receive messages while the `messages` property defines a key-value pair where each key corresponds to the event it's set up to handle.
+
+The WebSocket URL generated for `Heart-Counter` includes authentication tokens. This information is represented using `query` parameters. Query parameters are specific to HTTP protocol and partially to WebSocket, which uses HTTP to connect client and server. Since this is protocol-specific information, you must use an AsyncAPI feature called `bindings` that enables you to provide protocol-specific information inside the AsyncAPI document using the `bindings` attribute. By utilizing the `query` object from the WebSocket binding, you can outline the parameters needed for the connection and the conditions they must meet.
+
+
+{`channels:
+ root:
+ address: /
+ messages:
+ hello:
+ $ref: '#/components/messages/hello'
+ reaction:
+ $ref: '#/components/messages/reaction'
+ bindings:
+ ws:
+ query:
+ type: object
+ description: Tokens are produced in the WebSocket URL generated from the [apps.connections.open](https://api.slack.com/methods/apps.connections.open) method from Slack’s API
+ properties:
+ ticket:
+ type: string
+ description: Temporary token generated when connection is initiated
+ const: '13748dac-b866-4ea7-b98e-4fb7895c0a7f'
+ app_id:
+ type: string
+ description: Unique identifier assigned to the Slack app
+ const: 'fe684dfa62159c6ac646beeac31c8f4ef415e4f39c626c2dbd1530e3a690892f' `}
+
+
+## Define operations
+The `operation` property is all about defining specific tasks your application can perform. Essentially, it's how the `Heart-Counter` interacts with Slack.
+
+In this example, the `helloListener` operation keeps an eye out for the message sent by the Slack server when a WebSocket connection is successfully established. On the other hand, the `reactionListener` is focused on the `reaction_added` event type.
+
+Your Slack application is designed to be notified of events within your workspace. It subscribes to a specific event type and uses Slack's Event API. In this case, both operations' `action` property is set to `receive` events.
+
+
+{`operations:
+ helloListener:
+ action: receive
+ channel:
+ $ref: '#/channels/root'
+ messages:
+ - $ref: '#/channels/root/messages/hello'
+ reactionListener:
+ action: receive
+ channel:
+ $ref: '#/channels/root'
+ messages:
+ - $ref: '#/channels/root/messages/reaction' `}
+
+
+Congratulations, you've completed the tutorial! Putting these blocks together gives you an AsyncAPI document all ready to go.
+
+
+{`asyncapi: '3.0.0'
+info:
+ title: Create an AsyncAPI document for a Slackbot with WebSocket
+ version: '1.0.0'
+ description: |
+ The Heart-Counter manages popular messages in a Slack workspace by monitoring message reaction data.
+servers:
+ production:
+ host: wss-primary.slack.com
+ pathname: /link
+ protocol: wss
+ description: Slack's server in Socket Mode for real-time communication
+channels:
+ root:
+ address: /
+ messages:
+ hello:
+ $ref: '#/components/messages/hello'
+ reaction:
+ $ref: '#/components/messages/reaction'
+ bindings:
+ ws:
+ query:
+ type: object
+ description: Tokens are produced in the WebSocket URL generated from the [apps.connections.open](https://api.slack.com/methods/apps.connections.open) method from Slack’s API
+ properties:
+ ticket:
+ type: string
+ description: Temporary token generated when connection is initiated
+ const: '13748dac-b866-4ea7-b98e-4fb7895c0a7f'
+ app_id:
+ type: string
+ description: Unique identifier assigned to the Slack app
+ const: 'fe684dfa62159c6ac646beeac31c8f4ef415e4f39c626c2dbd1530e3a690892f'
+operations:
+ helloListener:
+ action: receive
+ channel:
+ $ref: '#/channels/root'
+ messages:
+ - $ref: '#/channels/root/messages/hello'
+ reactionListener:
+ action: receive
+ channel:
+ $ref: '#/channels/root'
+ messages:
+ - $ref: '#/channels/root/messages/reaction'
+components:
+ messages:
+ reaction:
+ summary: Action triggered when the channel receives a new reaction-added event
+ payload:
+ $ref: '#/components/schemas/reaction'
+ hello:
+ summary: Action triggered when a successful WebSocket connection is established
+ payload:
+ $ref: '#/components/schemas/hello'
+schemas:
+ hello:
+ type: object
+ properties:
+ type:
+ type: string
+ description: A hello string confirming WebSocket connection
+ connection_info:
+ type: object
+ properties:
+ app_id:
+ type: string
+ num_connections:
+ type: integer
+ debug_info:
+ type: object
+ properties:
+ host:
+ type: string
+ started:
+ type: string
+ build_number:
+ type: integer
+ approximate_connection_time:
+ type: integer
+ reaction:
+ type: object
+ properties:
+ user:
+ type: string
+ description: User ID who performed this event
+ reaction:
+ type: string
+ description: The only reaction that we need is a heart emoji
+ item_user:
+ type: string
+ description: User ID that created the original item that has been reacted to
+ item:
+ type: object
+ properties:
+ channel:
+ type: string
+ description: Channel information of original message
+ ts:
+ type: string
+ description: Timestamp information of original message
+ event_ts:
+ type: string
+ description: Reaction timestamp `}
+
+
+
+
+## Summary
+In this tutorial, you learned to create an AsyncAPI document for a Slackbot using WebSocket in Socket Mode. You gained practical insights into the functionality of operations, channels, messages, and schemas. Now you're equipped to handle real-world applications that facilitate bidirectional real-time data exchange, such as chatbots and live-streaming platforms.
diff --git a/pages/docs/tutorials/websocket/websocket-request-reply.md b/pages/docs/tutorials/websocket/websocket-request-reply.md
new file mode 100644
index 000000000000..5441d2a63020
--- /dev/null
+++ b/pages/docs/tutorials/websocket/websocket-request-reply.md
@@ -0,0 +1,370 @@
+---
+title: Implement Request/Reply in an AsyncAPI document for a Slack app
+description: In this tutorial, you'll learn how to write an AsyncAPI document that implements the request/reply feature in a Slack application using the WebSocket protocol.
+weight: 220
+---
+
+## Introduction
+In the [Create an AsyncAPI Document for a Slackbot with WebSockets](https://www.asyncapi.com/docs/tutorials/websocket) tutorial, you learned how to write an AsyncAPI document for a Slackbot `Heart-Counter` that actively monitored reactions associated with a message. In this lesson, let's go a step further. After receiving a reaction, `Heart-Counter` responds via a message back to the Slack server through WebSocket to confirm the event reception.
+
+The interaction where the Slackbot acknowledges the event and replies with a specific response sets the stage for the Request/Reply messaging pattern discussed in this context.
+
+> Refer to the [Request/Reply pattern tutorial](https://www.asyncapi.com/docs/tutorials/getting-started/request-reply) for an introduction to its implementation.
+
+
+```mermaid
+sequenceDiagram
+participant Heart-Counter
+participant Slack Server (Socket Mode)
+participant User
+
+
+User-->>Slack Server (Socket Mode): Adds emoji to a message.
+
+
+Slack Server (Socket Mode)->>Heart-Counter: Sending "reaction_added" payload
+Note left of Heart-Counter: Event received
+Heart-Counter->>Slack Server (Socket Mode): Sending acknowledgement
+```
+
+
+## Background context
+
+The [Request-Reply Messaging Pattern](https://www.asyncapi.com/docs/concepts/asyncapi-document/reply-info) in AsyncAPI is an exciting and highly anticipated feature. The messaging pattern mirrors a traditional conversation, where one "requester" entity initiates a query or request, and the "responder" entity provides a specific and expected response.
+The messaging pattern can work in both synchronous and asynchronous environments and is very beneficial to decouple components by allowing them to operate independently in a distributed system.
+
+```mermaid
+sequenceDiagram
+ participant Client
+ participant Server
+
+ Client->>Server: Request
+ note right of Client: Continue with other tasks
+
+ Server-->>Client: Acknowledgment
+ Server->>Server: Process Request
+ Server-->>Client: Reply
+```
+
+
+## Define messages
+
+In the `Heart-Counter` tutorial, you dealt with the `hello` event triggered when the WebSocket connection was established and the `reaction` event expected when a new reaction-added event was triggered.
+
+In this tutorial, you'll add the `acknowledge` message to your AsyncAPI document to represent the acknowledgment sent by the Slack application back to the server to indicate that it has successfully received the message.
+
+
+{`components:
+ messages:
+ reaction:
+ summary: Action triggered when the channel receives a new reaction-added event
+ payload:
+ $ref: '#/components/schemas/reaction'
+ hello:
+ summary: Action triggered when a successful WebSocket connection is established
+ payload:
+ $ref: '#/components/schemas/hello'
+ acknowledge:
+ summary: Acknowledgement response sent to Server
+ payload:
+ $ref: '#/components/schemas/acknowledge' `}
+
+
+## Define schemas
+
+Previously, the `reaction` schema was simplified to include the `event` payload. However, in this instance, you will be able to elaborate on the schema for the complete request it is expected to receive.
+
+
+The sample request and response payloads are extracted from Slack's official documentation .
+
+
+
+{` schemas:
+ hello:
+ type: object
+ properties:
+ type:
+ type: string
+ description: A hello string confirming WebSocket connection
+ connection_info:
+ type: object
+ properties:
+ app_id:
+ type: string
+ num_connections:
+ type: integer
+ debug_info:
+ type: object
+ properties:
+ host:
+ type: string
+ started:
+ type: string
+ build_number:
+ type: integer
+ approximate_connection_time:
+ type: integer
+ reaction:
+ type: object
+ properties:
+ envelope_id:
+ type: string
+ description: 'Unique ID assigned to payload'
+ payload:
+ type: object
+ description: 'Payload of the reaction added event'
+ properties:
+ token:
+ type: string
+ team_id:
+ type: string
+ event:
+ type: object
+ properties:
+ user:
+ type: string
+ description: User ID who performed this event
+ reaction:
+ type: string
+ description: The only reaction that you need is a heart emoji
+ item_user:
+ type: string
+ description: |
+ User ID that created the original item that has been reacted
+ to
+ item:
+ type: object
+ properties:
+ channel:
+ type: string
+ description: Channel information of original message
+ ts:
+ type: string
+ description: Timestamp information of original message
+ event_ts:
+ type: string
+ description: Reaction timestamp
+ type:
+ type: string
+ accepts_response_payload:
+ type: boolean `}
+
+
+Additionally, you will also be adding the `acknowledge` schema that makes use of the `envelope_id` attribute to send a reply back to Slack acknowledging that event has been received.
+
+
+{` acknowledge:
+ type: object
+ properties:
+ envelope_id:
+ type: string
+ description: 'Unique ID of acknowledged payload'
+ payload:
+ type: object
+ description: 'Optional payload of event' `}
+
+
+## Define acknowledge message to channel
+Extend the channel the `Heart-Counter` used to include the `acknowledge` message.
+
+
+{`channels:
+ root:
+ address: /
+ messages:
+ hello:
+ $ref: '#/components/messages/hello'
+ reaction:
+ $ref: '#/components/messages/reaction'
+ acknowledge:
+ $ref: '#/components/messages/acknowledge' `}
+
+
+## Define operations
+
+Now you've reached the most important part of the tutorial; it's time to represent the Request/Reply pattern.
+
+Both `helloListener` and `reactionListener` operations are set to `receive` events. However, in the case of `reactionListener`, you also want to represent the message sent back to the server. This is where the `reply` attribute comes into play.
+
+Since both the request and reply function happens over the same WebSocket URL, both `channel` values stay the same. However, you can differentiate each operation's message by specifying the messages sent or received.
+Thus, you can say that for a `reaction` message received over the `root` channel, the `reactionListener` operation will reply with the `acknowledge` message over the same channel.
+
+
+
+{`operations:
+ helloListener:
+ action: receive
+ channel:
+ $ref: '#/channels/root'
+ messages:
+ - $ref: '#/channels/root/messages/hello'
+ reactionListener:
+ action: receive
+ channel:
+ $ref: '#/channels/root'
+ messages:
+ - $ref: '#/channels/root/messages/reaction'
+ reply:
+ messages:
+ - $ref: '#/channels/root/messages/acknowledge'
+ channel:
+ $ref: '#/channels/root' `}
+
+
+Putting all this together, you have your AsyncAPI document ready to go!
+
+{`asyncapi: 3.0.0
+info:
+ title: Implement Request/Reply in an AsyncAPI document for a Slack app
+ version: 1.0.0
+ description: >
+ The Heart-Counter manages popular messages in a Slack workspace by
+ monitoring message reaction data. It also sends an acknowledgment message
+ back to the Slack Server to indicate it has received the message.
+servers:
+ production:
+ host: wss-primary.slack.com
+ pathname: /link
+ protocol: wss
+ description: Slack's server in Socket Mode for real-time communication
+channels:
+ root:
+ address: /
+ messages:
+ hello:
+ $ref: '#/components/messages/hello'
+ reaction:
+ $ref: '#/components/messages/reaction'
+ acknowledge:
+ $ref: '#/components/messages/acknowledge'
+ bindings:
+ ws:
+ query:
+ type: object
+ description: >-
+ Tokens are produced in the WebSocket URL generated from the
+ [apps.connections.open](https://api.slack.com/methods/apps.connections.open)
+ method from Slack's API
+ properties:
+ ticket:
+ type: string
+ description: Temporary token generated when connection is initiated
+ const: 13748dac-b866-4ea7-b98e-4fb7895c0a7f
+ app_id:
+ type: string
+ description: Unique identifier assigned to the Slack app
+ const: fe684dfa62159c6ac646beeac31c8f4ef415e4f39c626c2dbd1530e3a690892f
+operations:
+ helloListener:
+ action: receive
+ channel:
+ $ref: '#/channels/root'
+ messages:
+ - $ref: '#/channels/root/messages/hello'
+ reactionListener:
+ action: receive
+ channel:
+ $ref: '#/channels/root'
+ messages:
+ - $ref: '#/channels/root/messages/reaction'
+ reply:
+ messages:
+ - $ref: '#/channels/root/messages/acknowledge'
+ channel:
+ $ref: '#/channels/root'
+components:
+ messages:
+ reaction:
+ summary: Action triggered when the channel receives a new reaction-added event
+ payload:
+ $ref: '#/components/schemas/reaction'
+ hello:
+ summary: Action triggered when a successful WebSocket connection is established
+ payload:
+ $ref: '#/components/schemas/hello'
+ acknowledge:
+ summary: Acknowledgement response sent to Server
+ payload:
+ $ref: '#/components/schemas/acknowledge'
+ schemas:
+ hello:
+ type: object
+ properties:
+ type:
+ type: string
+ description: A hello string confirming WebSocket connection
+ connection_info:
+ type: object
+ properties:
+ app_id:
+ type: string
+ num_connections:
+ type: integer
+ debug_info:
+ type: object
+ properties:
+ host:
+ type: string
+ started:
+ type: string
+ build_number:
+ type: integer
+ approximate_connection_time:
+ type: integer
+ reaction:
+ type: object
+ properties:
+ envelope_id:
+ type: string
+ description: 'Unique ID assigned to payload'
+ payload:
+ type: object
+ description: 'Payload of the reaction added event'
+ properties:
+ token:
+ type: string
+ team_id:
+ type: string
+ event:
+ type: object
+ properties:
+ user:
+ type: string
+ description: User ID who performed this event
+ reaction:
+ type: string
+ description: The only reaction that you need is a heart emoji
+ item_user:
+ type: string
+ description: |
+ User ID that created the original item that has been reacted
+ to
+ item:
+ type: object
+ properties:
+ channel:
+ type: string
+ description: Channel information of original message
+ ts:
+ type: string
+ description: Timestamp information of original message
+ event_ts:
+ type: string
+ description: Reaction timestamp
+ type:
+ type: string
+ accepts_response_payload:
+ type: boolean
+ acknowledge:
+ type: object
+ properties:
+ envelope_id:
+ type: string
+ description: 'Unique ID of acknowledged payload'
+ payload:
+ type: object
+ description: 'Optional payload of event' `}
+
+
+## Summary
+Great job getting to the end! In this tutorial, you learned how to create an AsyncAPI document for a use case that implemented the Request-Reply messaging pattern. Now, you can explore this pattern with sub-patterns to see how it works with real-life use cases.
diff --git a/pages/index.js b/pages/index.js
index 67f9185d4923..c5bc7fed2b39 100644
--- a/pages/index.js
+++ b/pages/index.js
@@ -1,261 +1,24 @@
-import Container from '../components/layout/Container'
import NavBar from '../components/navigation/NavBar'
-import Hero from '../components/Hero'
-import NewsletterSubscribe from '../components/NewsletterSubscribe'
-import Sponsors from '../components/sponsors/Sponsors'
import Head from '../components/Head'
-import Slack from '../components/slack'
-import Button from '../components/buttons/Button'
-import Calendar from '../components/Calendar'
-import AdidasLogo from '../components/logos/Adidas'
-import AxwayLogo from '../components/logos/Axway'
-import SlackLogo from '../components/logos/Slack'
-import SalesforceLogo from '../components/logos/Salesforce'
-import SapLogo from '../components/logos/SAP'
-import Testimonial from '../components/Testimonial'
-import Heading from '../components/typography/Heading'
-import Paragraph from '../components/typography/Paragraph'
-import TextLink from '../components/typography/TextLink'
-import GoldSponsors from '../components/sponsors/GoldSponsors'
-import SilverSponsors from '../components/sponsors/SilverSponsors'
-import SupportUs from '../components/SupportUs/SupportUs'
import StickyNavbar from '../components/navigation/StickyNavbar'
-import GoogleCalendarButton from '../components/buttons/GoogleCalendarButton';
-import ICSFileButton from '../components/buttons/ICSFileButton';
-import SubscribeButton from '../components/buttons/SubscribeButton';
-import NewsroomSection from '../components/newsroom/NewsroomSection'
import { languageDetection } from "../lib/i18n";
function HomePage() {
- //To be enabled in a future PR
- //languageDetection();
+ const loader = 'img/loaders/loader.png'; // preloader image for the tools
+ languageDetection();
+
return (
<>
-
-
-
-
-
-
-
-
- Adopted by the world leading brands
-
-
- These brands are already using AsyncAPI in production. Is your company using AsyncAPI and wants to be included in this list?
-
- Let us know here!
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
+
+
+
+
Loading...
-
-
-
- Join our great community!
-
-
- We're a community of great people who are passionate about AsyncAPI and event-driven architectures.
-
-
-
-
-
-
-
-
-
-
- Join our Slack workspace
-
-
- We welcome everyone to join our Slack workspace. If you have a question on how to use AsyncAPI, want to contribute, or simply want to say hello 👋 you're welcome to join us. We're nice people 🙂
-
-
-
-
-
-
-
-
-
-
-
-
-
- Join our public meetings
-
-
- AsyncAPI hosts different meetings every week. They are focused on different topic, sometimes purely technical and sometimes about community building. Pick one and join us!
-
-
- Learn more about our meetings.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Platinum Sponsors
-
-
-
-
-
-
- Gold Sponsors
-
-
-
-
-
-
- Silver Sponsors
-
-
-
-
-
-
-
- Want to Sponsor Us?
-
-
- These great organizations are already supporting AsyncAPI. Want to become a sponsor?
-
- Support us!
-
-
-
-
-
-
- Supported by
-
-
- The following companies support us by letting us use their products for free. Interested in supporting us too?
-
- Email us
- for more info.
-
-
-
-
-
- What the experts are saying
-
-
-
-
+
>
)
}
diff --git a/scripts/finance/index.js b/scripts/finance/index.js
index d720bfd989a3..b0954a8e582d 100644
--- a/scripts/finance/index.js
+++ b/scripts/finance/index.js
@@ -6,8 +6,8 @@ module.exports = async function buildFinanceInfoList() {
try {
const currentDir = resolve(__dirname, '../../');
- const expensesPath = resolve(currentDir, 'config', 'finance', '2023', 'Expenses.yml');
- const expensesLinkPath = resolve(currentDir, 'config', 'finance', '2023', 'ExpensesLink.yml');
+ const expensesPath = resolve(currentDir, 'config', 'finance', '2024', 'Expenses.yml');
+ const expensesLinkPath = resolve(currentDir, 'config', 'finance', '2024', 'ExpensesLink.yml');
const ExpensesContent = await readFile(expensesPath, 'utf-8');
const ExpensesLinkContent = await readFile(expensesLinkPath, 'utf-8');
@@ -16,7 +16,7 @@ module.exports = async function buildFinanceInfoList() {
const ExpensesLink = convertToJson(ExpensesLinkContent);
// Ensure the directory exists before writing the files
- const jsonDirectory = resolve(currentDir, 'config', 'finance', 'json-data', '2023');
+ const jsonDirectory = resolve(currentDir, 'config', 'finance', 'json-data', '2024');
await mkdir(jsonDirectory, { recursive: true });
// Write Expenses to a JSON files