website
website copied to clipboard
docs: add message concepts doc
Description
This PR adds the new message
concept spec
Related issue(s)
- Fixes #941
Deploy Preview for asyncapi-website ready!
Built without sensitive environment variables
Name | Link |
---|---|
Latest commit | f404566410dea8a8f9bdd48ed8d18723f35c3a01 |
Latest deploy log | https://app.netlify.com/sites/asyncapi-website/deploys/636c22d9a02316000814955f |
Deploy Preview | https://deploy-preview-944--asyncapi-website.netlify.app |
Preview on mobile | Toggle QR Code...Use your smartphone camera to open QR code link. |
To edit notification comments on pull requests, go to your Netlify site settings.
Hey, @derberg here is the proper PR, thank you 😅
I need help in defining the purpose of the message concept as well as the diagram.
cc. @smoya
@thulieblack
- I'm not sure it is possible to represent message concept with a diagram. Can't think of any example
- I do think it would be a good place to address a question about what is the difference between event and message 😄 maybe even title could be
Message vs Event
. I'm not sure I want to be part of this academic discussion 😆
I recommend looking at:
- https://developer.lightbend.com/docs/akka-platform-guide/concepts/message-driven-event-driven.html
- https://bradirby.com/difference-between-event-and-message/
- https://www.reactivemanifesto.org/glossary#Message-Driven
Also, I could not help myself, and dragged community into discussion, let's see if they catch a bait 😃
- https://www.linkedin.com/feed/update/urn:li:activity:6975192181678436352
- https://twitter.com/AsyncAPISpec/status/1569426365903953921
Also, a question I always wanted to ask @fmvilas
"do you recall why we talk about making it easier to work with event-driven architectures, but in spec we have Messages
and not Events
" 🍿
Also, a question I always wanted to ask @fmvilas "do you recall why we talk about making it easier to work with event-driven architectures, but in spec we have Messages and not Events" 🍿
@derberg Does this reply to your question? https://www.asyncapi.com/docs/tutorials/getting-started/event-driven-architectures#why-event-driven-and-not-message-driven
@fmvilas not really. I'm more interested if there was some specific reason why we picked to use two terms. Maybe some old issue about it? or maybe you remember 😄
Haha! I do know why. Strictly speaking, it's all "messages". A message can be an event, a command, and maybe something else (although I never found a 3rd kind). The spec is a formal document so "message" seems appropriate here. Now that said, event-driven architectures have become more popular in recent years (with the rise of RabbitMQ, Kafka, etc.). And yeah, I mean "event-driven" architectures. Using events only. However, the more popular it got, the more people started doing not-just-events-driven architectures. See, for instance, the case of CQRS (Command-Query Responsibility Segregation). Again, strictly speaking, these are message-driven architectures but the reality is that this name never got popular and most of us are just using event-driven architectures to refer to both, message-driven architectures and event-driven architectures 🤷♂️ I guess it sounds cooler with "event" and that won 😄
So for strict stuff like the spec, it's "message" and for communication or marketing, it's "event" because that's what people tend to use the most.
Okay so now my question @fmvilas is, should we still go ahead and define the message
spec concept or ....?
@thulieblack we need message
as this is what we have in spec. But we also need to address these "event vs message" definitions, to make it clear where to draw the line. So we explain the message, and also add event 😄
btw, I got you lots of ideas 😄 -> https://twitter.com/AsyncAPISpec/status/1569426365903953921 and https://www.linkedin.com/feed/update/urn:li:activity:6975192181678436352?commentUrn=urn%3Ali%3Acomment%3A%28activity%3A6975192181678436352%2C6975358655713980416%29 (I did not expect such a great response from the community 🚀 )
Looks good to me, @thulieblack. I think we should keep it as simple as possible on this page. Maybe you want to mark this PR as ready for review?
⚡️ Lighthouse report for the changes in this PR:
Category | Score |
---|---|
🟠 Performance | 52 |
🟠 Accessibility | 88 |
🟠 Best practices | 83 |
🟢 SEO | 100 |
🔴 PWA | 30 |
Lighthouse ran on https://deploy-preview-944--asyncapi-website.netlify.app/
Looks good to me, @thulieblack. I think we should keep it as simple as possible on this page. Maybe you want to mark this PR as ready for review?
Done 👌
@alequetzalli / @fmvilas over to you 🤓
@alequetzalli I think this is also ready for a final review. Hey @derberg and @fmvilas 😊😊
/rtm
@alequetzalli please always make sure you align the Prev and UpNext buttons properly for adjacent pages also, before merging the PR. I see that with this PR, we again have an issue in Channel
page and Tutorials - Overview
page. Since we are adding new pages to the documentation, it can't be possible to make separate issue for each page and someone else should come to resolve the error. These buttons should be thoroughly checked until some automation is established for this.
I revised this and all of the buttons work, there is no problem in this PR.
@alequetzalli Look into the screenshots below, they are of Channel
and Tutorials - Overview
page. The UpNext button of Channel page and Prev Button of Tutorials - Overview.
Prev Button of Tutorials - Overview page:
UpNext Button of Channel page:
These buttons has to be updated in this PR, while adding new page in between.
@Akshatnema yes, every time a new page is added these buttons will need to be updated and that is correct. Yes, we need a new PR to fix the previous page buttons and that is fine.
Her buttons on this page are correct and there is nothing to fix.
@alequetzalli Yeah, I agree that she added buttons in the page in correct way, but it has to be ensured that every time, a new page is added in docs, it shouldn't break the sequence of the pages linked. For every new page created and added, the buttons should be added on that page and should be updated for the immediate next and previous page.
I can't say that this is the job of who created Channel
page because it was added earlier, so if anyone adds any new page in the docs, he has to make changes in the buttons of 3 pages exactly: present new page, immediate next page and previous page.
I think what you are saying @akshatnema is that per every page pushed/added to the website someone needs to update the previous page buttons so they align properly.
every page pushed/added to the website someone needs to update the previous page buttons so they align properly.
Exactly :+1:
I have created a PR #1100 to solve this issue @alequetzalli and @akshatnema