Editing article

Title

Summary

Content

Almost one year ago, I talked about <a href="https://www.asyncapi.com/">AsyncAPI</a> 2.6 and how confusing its publish and subscribe operations can be in my <a href="https://atamel.dev/posts/2023/05-18_asyncapi_publishsubscribe_refactor">Understanding AsyncAPI&#39;s publish &amp; subscribe semantics with an example</a> post.Since then, a new 3.0 version of AsyncAPI has been released with breaking changes and a totally new send and receive operations.In this blog post, I want to revisit the example from last year and show how to rewrite it for AsyncAPI 3.0 with the new send and receive operations.<h3>AsyncAPI 3.0</h3>AsyncAPI 3.0 was released in December 2023. Since it&#39;s a major version, it has some breaking changes. These two pages does a good job explaining the changes and the rationale behind them:<ul><li><a href="https://www.asyncapi.com/blog/release-notes-3.0.0">AsyncAPI 3.0.0 Release Notes</a>.</li><li><a href="https://www.asyncapi.com/docs/migration/migrating-to-v3">Migrating to v3</a>.</li></ul>I won’t go through all the changes. For me, the biggest change is the separation of operations and channels, and changing publish and subscribe operations to send and receive.<figure><img alt="" src="https://cdn-images-1.medium.com/max/693/0*JRRNdhOa9QSlg9u_.png" /></figure><h3>Recap: Publish and subscribe operations in AsyncAPI 2.6</h3>As a recap, AsyncAPI 2.6 has the following publish and subscribe operations with these semantics:<figure><img alt="" src="https://cdn-images-1.medium.com/max/783/1*qt82k4Q2nNRNfxRTiEz9xA.png" /></figure>In 2.6, publish and subscribe operations are from user&#39;s perspective.<h3>New: Send and receive operations in AsyncAPI 3.0</h3>In 3.0, the publish and subscribe operations are replaced with send and receive operations. In <a href="https://www.asyncapi.com/docs/migration/migrating-to-v3">Migrating to v3</a> page, the rationale is given as follows:<blockquote>In v2, the publish and subscribe operations consistently caused confusion, even among those familiar with the intricacies.</blockquote><blockquote>When you specified publish, it implied that others could publish to this channel since your application subscribed to it. Conversely, subscribe meant that others could subscribe because your application was the one publishing.</blockquote><blockquote>In v3, these operations have been entirely replaced with an action property that clearly indicates what your application does. That eliminates ambiguities related to other parties or differing perspectives.</blockquote>While I agree that publish and subscribe were confusing, I&#39;m not sure if send and receive are less confusing. You still need to talk about whose perspective when defining these operations. AsyncAPI docs talk about application but that&#39;s not clear either. Does application refer to the code sending the message (user) or the code receiving the message (server)?In Async 3.0, send and receive operations are from server&#39;s perspective. An example will clarify.<h3>Account and Email Services</h3>Let’s revisit our example from last year. You have two microservices: Account Service emits an userSignedUp event and Email Service receives that event:<figure><img alt="" src="https://cdn-images-1.medium.com/max/720/0*9Ydxd0aMTSxeLya1" /></figure>How do you define such an architecture in AsyncAPI 2.6 vs 3.0?<h3>Account Service</h3>For Account Service, in 2.6, you had to define a channel with subscribe operation because the user has to subscribe to receive messages:<pre>asyncapi: 2.6.0 channels: user/signedup: subscribe: operationId: publishUserSignedUp message: $ref: &#39;#/components/messages/userSignedUp&#39;</pre><a href="https://github.com/meteatamel/asyncapi-basics/blob/main/samples/account-email-services/account-service-2.6.yaml">account-service-2.6.yaml</a>In 3.0, the channel does not have an operation anymore. Instead, there&#39;s a new publishUserSignedUp operation with send action that refers to the channel. This is because the server sends the message:<pre>asyncapi: 3.0.0 channels: user/signedup: address: user/signedup messages: publishUserSignedUp.message: $ref: &#39;#/components/messages/userSignedUp&#39; operations: publishUserSignedUp: action: send channel: $ref: &#39;#/channels/user~1signedup&#39; messages: - $ref: &#39;#/channels/user~1signedup/messages/publishUserSignedUp.message&#39;</pre><a href="https://github.com/meteatamel/asyncapi-basics/blob/main/samples/account-email-services/account-service-3.0.yaml">account-service-3.0.yaml</a><h3>Email Service</h3>Similarly, in Email Service, in 2.6, you had to define a publish operation because the user had to publish a message to the server:<pre>asyncapi: 2.6.0 channels: user/signedup: publish: operationId: receiveUserSignedUp message: $ref : &#39;#/components/messages/userSignedUp&#39;</pre><a href="https://github.com/meteatamel/asyncapi-basics/blob/main/samples/account-email-services/email-service-2.6.yaml">email-service-2.6.yaml</a>However, in 3.0, the server receives a message, so the operation has receive action:<pre>asyncapi: 3.0.0 channels: user/signedup: address: user/signedup messages: receiveUserSignedUp.message: $ref: &#39;#/components/messages/userSignedUp&#39; operations: receiveUserSignedUp: action: receive channel: $ref: &#39;#/channels/user~1signedup&#39; messages: - $ref: &#39;#/channels/user~1signedup/messages/receiveUserSignedUp.message&#39;</pre>In this blog post, I explored a small part of AsyncAPI and explained the differences between 2.6 operations publish and subscribe and 3.0 operations send and receive. In a nutshell, in 2.6, you need to think from user&#39;s perspective and in 3.0 in server&#39;s perspective when you define these operations.If you’re interested in learning more, I have a talk on CloudEvents and AsyncAPI and a repo with some samples:<ul><li><a href="https://speakerdeck.com/meteatamel/open-standards-for-building-event-driven-applications-in-the-cloud">Open standards for building event-driven applications in the cloud</a>.</li><li><a href="https://github.com/meteatamel/asyncapi-basics/">asyncapi-basics</a></li></ul>Originally published at <a href="https://atamel.dev/posts/2024/05-13_asyncapi_30_send_receive/">https://atamel.dev</a>.<img src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=013dd1d6265b" width="1" height="1" alt=""><hr><a href="https://medium.com/google-cloud/asyncapi-gets-a-new-version-3-0-and-new-operations-013dd1d6265b">AsyncAPI gets a new version 3.0 and new operations</a> was originally published in <a href="https://medium.com/google-cloud">Google Cloud - Community</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Author

Link

Published date

Image url

Feed url

Guid

Hidden blurb

--- !ruby/object:Feedjira::Parser::RSSEntry
title: AsyncAPI gets a new version 3.0 and new operations
url: https://medium.com/google-cloud/asyncapi-gets-a-new-version-3-0-and-new-operations-013dd1d6265b?source=rss----e52cf94d98af---4
author: Mete Atamel
categories:
- software-development
- software-engineering
- open-source
- event-driven-architecture
published: 2024-05-13 08:32:53.000000000 Z
entry_id: !ruby/object:Feedjira::Parser::GloballyUniqueIdentifier
 is_perma_link: 'false'
 guid: https://medium.com/p/013dd1d6265b
carlessian_info:
 news_filer_version: 2
 newspaper: Google Cloud - Medium
 macro_region: Blogs
rss_fields:
- title
- url
- author
- categories
- published
- entry_id
- content
content: 'Almost one year ago, I talked about <a href="https://www.asyncapi.com/">AsyncAPI</a>
 2.6 and how confusing its publish and subscribe operations can be in my <a href="https://atamel.dev/posts/2023/05-18_asyncapi_publishsubscribe_refactor">Understanding
 AsyncAPI&#39;s publish &amp; subscribe semantics with an example</a> post.Since
 then, a new 3.0 version of AsyncAPI has been released with breaking changes and
 a totally new send and receive operations.In this blog post, I want to revisit
 the example from last year and show how to rewrite it for AsyncAPI 3.0 with the
 new send and receive operations.<h3>AsyncAPI 3.0</h3>AsyncAPI 3.0 was released
 in December 2023. Since it&#39;s a major version, it has some breaking changes.
 These two pages does a good job explaining the changes and the rationale behind them:<ul><li><a
 href="https://www.asyncapi.com/blog/release-notes-3.0.0">AsyncAPI 3.0.0 Release Notes</a>.</li><li><a
 href="https://www.asyncapi.com/docs/migration/migrating-to-v3">Migrating to v3</a>.</li></ul>I
 won’t go through all the changes. For me, the biggest change is the separation of
 operations and channels, and changing publish and subscribe operations to send and receive.<figure><img
 alt="" src="https://cdn-images-1.medium.com/max/693/0*JRRNdhOa9QSlg9u_.png" /></figure><h3>Recap:
 Publish and subscribe operations in AsyncAPI 2.6</h3>As a recap, AsyncAPI 2.6
 has the following publish and subscribe operations with these semantics:<figure><img
 alt="" src="https://cdn-images-1.medium.com/max/783/1*qt82k4Q2nNRNfxRTiEz9xA.png"
 /></figure>In 2.6, publish and subscribe operations are from user&#39;s
 perspective.<h3>New: Send and receive operations in AsyncAPI 3.0</h3>In
 3.0, the publish and subscribe operations are replaced with send and receive operations.
 In <a href="https://www.asyncapi.com/docs/migration/migrating-to-v3">Migrating to
 v3</a> page, the rationale is given as follows:<blockquote>In v2, the publish
 and subscribe operations consistently caused confusion, even among those familiar
 with the intricacies.</blockquote><blockquote>When you specified publish, it implied
 that others could publish to this channel since your application subscribed to it.
 Conversely, subscribe meant that others could subscribe because your application
 was the one publishing.</blockquote><blockquote>In v3, these operations have been
 entirely replaced with an action property that clearly indicates what your application
 does. That eliminates ambiguities related to other parties or differing perspectives.</blockquote>While
 I agree that publish and subscribe were confusing, I&#39;m not sure if send and
 receive are less confusing. You still need to talk about whose perspective when
 defining these operations. AsyncAPI docs talk about application but that&#39;s
 not clear either. Does application refer to the code sending the message (user)
 or the code receiving the message (server)?In Async 3.0, send and receive
 operations are from server&#39;s perspective. An example will clarify.<h3>Account
 and Email Services</h3>Let’s revisit our example from last year. You have two
 microservices: Account Service emits an userSignedUp event and Email Service receives
 that event:<figure><img alt="" src="https://cdn-images-1.medium.com/max/720/0*9Ydxd0aMTSxeLya1"
 /></figure>How do you define such an architecture in AsyncAPI 2.6 vs 3.0?<h3>Account
 Service</h3>For Account Service, in 2.6, you had to define a channel with subscribe
 operation because the user has to subscribe to receive messages:<pre>asyncapi:
 2.6.0 channels: user/signedup: subscribe: operationId:
 publishUserSignedUp message: $ref: &#39;#/components/messages/userSignedUp&#39;</pre><a
 href="https://github.com/meteatamel/asyncapi-basics/blob/main/samples/account-email-services/account-service-2.6.yaml">account-service-2.6.yaml</a>In
 3.0, the channel does not have an operation anymore. Instead, there&#39;s a new
 publishUserSignedUp operation with send action that refers to the channel. This
 is because the server sends the message:<pre>asyncapi: 3.0.0 channels: user/signedup: address:
 user/signedup messages: publishUserSignedUp.message: $ref:
 &#39;#/components/messages/userSignedUp&#39; operations: publishUserSignedUp: action:
 send channel: $ref: &#39;#/channels/user~1signedup&#39; messages: -
 $ref: &#39;#/channels/user~1signedup/messages/publishUserSignedUp.message&#39;</pre><a
 href="https://github.com/meteatamel/asyncapi-basics/blob/main/samples/account-email-services/account-service-3.0.yaml">account-service-3.0.yaml</a><h3>Email
 Service</h3>Similarly, in Email Service, in 2.6, you had to define a publish
 operation because the user had to publish a message to the server:<pre>asyncapi:
 2.6.0 channels: user/signedup: publish: operationId:
 receiveUserSignedUp message: $ref : &#39;#/components/messages/userSignedUp&#39;</pre><a
 href="https://github.com/meteatamel/asyncapi-basics/blob/main/samples/account-email-services/email-service-2.6.yaml">email-service-2.6.yaml</a>However,
 in 3.0, the server receives a message, so the operation has receive action:<pre>asyncapi:
 3.0.0 channels: user/signedup: address: user/signedup messages: receiveUserSignedUp.message: $ref:
 &#39;#/components/messages/userSignedUp&#39; operations: receiveUserSignedUp: action:
 receive channel: $ref: &#39;#/channels/user~1signedup&#39; messages: -
 $ref: &#39;#/channels/user~1signedup/messages/receiveUserSignedUp.message&#39;</pre>In
 this blog post, I explored a small part of AsyncAPI and explained the differences
 between 2.6 operations publish and subscribe and 3.0 operations send and receive.
 In a nutshell, in 2.6, you need to think from user&#39;s perspective and in 3.0
 in server&#39;s perspective when you define these operations.If you’re interested
 in learning more, I have a talk on CloudEvents and AsyncAPI and a repo with some samples:<ul><li><a
 href="https://speakerdeck.com/meteatamel/open-standards-for-building-event-driven-applications-in-the-cloud">Open
 standards for building event-driven applications in the cloud</a>.</li><li><a href="https://github.com/meteatamel/asyncapi-basics/">asyncapi-basics</a></li></ul>Originally
 published at <a href="https://atamel.dev/posts/2024/05-13_asyncapi_30_send_receive/">https://atamel.dev</a>.<img
 src="https://medium.com/_/stat?event=post.clientViewed&referrerSource=full_rss&postId=013dd1d6265b"
 width="1" height="1" alt=""><hr><a href="https://medium.com/google-cloud/asyncapi-gets-a-new-version-3-0-and-new-operations-013dd1d6265b">AsyncAPI
 gets a new version 3.0 and new operations</a> was originally published in <a href="https://medium.com/google-cloud">Google
 Cloud - Community</a> on Medium, where people are continuing the conversation by
 highlighting and responding to this story.'

Language

Active

Ricc internal notes

Ricc source

Show this article Back to articles