docs: add producer concepts article

[nelsonmic]

trafficstars

Description This PR adds a NEW producer Conceptdoc and diagram.

Related issue(s)

• Fixes #798

[netlify[bot]]

✅ Deploy Preview for asyncapi-website ready!

Built without sensitive environment variables

Name	Link
🔨 Latest commit	afa61950aff14ce296d95a68f2ebed06890385b6
🔍 Latest deploy log	https://app.netlify.com/sites/asyncapi-website/deploys/633d9a5aec608600089b3e11
😎 Deploy Preview	https://deploy-preview-824--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.

[nelsonmic]

Hello all, here's a link to the figjam file with the draft diagram for the producer concept:

https://www.figma.com/file/UWBeuWCR0RnRkQv0jBt3HN/producers-concept?node-id=0%3A1

[smoya]

I'm going to copy paste a message I wrote on AsyncAPI Slack for another folk who created another diagram. https://asyncapi.slack.com/archives/C0230UAM6R3/p1655219125760849?thread_ts=1655137152.791769&cid=C0230UAM6R3

On top of what Lukasz mentioned, which is very critical, I will drop a couple of recommendations for creating diagrams like the one you want to create. Free to follow or discard of course:

• Important to use proper diagram shapes/symbols for each actor or connector. It doesn’t have to be very strict, but for example, a common symbol used for queues or channels look like a pipe or cylinder (my preference), e.g. https://i.stack.imgur.com/KiaTu.gif or a rectangle more but small ones inside, similar to an stack but horizontally e.g. https://i.stack.imgur.com/MgCkt.png
• Make the source of the diagram be available to users (the file or whatever you used for creating it), so in case anyone needs to improve it, they can without having to redo from scratch.
• This is a personal opinion, but I prefer horizontal diagrams when describing message passing or EDA’s as I found them natural to follow (from left to right). From top to bottom are not as natural as the horizontal. Most examples you will find out there are horizontal diagrams as well. (I guess our brain works better)

[quetzalliwrites]

I'm going to copy paste a message I wrote on AsyncAPI Slack for another folk who created another diagram. https://asyncapi.slack.com/archives/C0230UAM6R3/p1655219125760849?thread_ts=1655137152.791769&cid=C0230UAM6R3

@smoya Thank you for remembering to copy your feedback into the PR!

[nelsonmic]

I'm going to copy paste a message I wrote on AsyncAPI Slack for another folk who created another diagram. https://asyncapi.slack.com/archives/C0230UAM6R3/p1655219125760849?thread_ts=1655137152.791769&cid=C0230UAM6R3

On top of what Lukasz mentioned, which is very critical, I will drop a couple of recommendations for creating diagrams like the one you want to create. Free to follow or discard of course:

• Important to use proper diagram shapes/symbols for each actor or connector. It doesn’t have to be very strict, but for example, a common symbol used for queues or channels look like a pipe or cylinder (my preference), e.g. https://i.stack.imgur.com/KiaTu.gif or a rectangle more but small ones inside, similar to an stack but horizontally e.g. https://i.stack.imgur.com/MgCkt.png
• Make the source of the diagram be available to users (the file or whatever you used for creating it), so in case anyone needs to improve it, they can without having to redo from scratch.
• This is a personal opinion, but I prefer horizontal diagrams when describing message passing or EDA’s as I found them natural to follow (from left to right). From top to bottom are not as natural as the horizontal. Most examples you will find out there are horizontal diagrams as well. (I guess our brain works better)

@smoya thank you so much for your feedback

[nelsonmic]

https://www.figma.com/file/UWBeuWCR0RnRkQv0jBt3HN/producers-concept?node-id=0%3A

@alequetzalli @derberg I made some changes to the diagram

[derberg]

I'm wondering if it would lake sense to already add to this diagram, or maybe another version, the component that is called Producer/Consumer, because the things is that it can also be like that, that one service that is a Producer or Message 1 can also a Consumer of Message 2

[quetzalliwrites]

I'm wondering if it would lake sense to already add to this diagram, or maybe another version, the component that is called Producer/Consumer, because the things is that it can also be like that, that one service that is a Producer or Message 1 can also a Consumer of Message 2

Oh wait.. 🤔 I don't think I am 100% following... can you explain more details of what you mean here? I think I mostly get it but I think I need a more detailed written example @derberg

[derberg]

sorry, so I mean that basically it is not only that you have either producers or subscribers. You can have also an entity that is a producer and consumer at the same time, like in my onboarding session and Flight Monitor Service that not only consumes messages but also produces other messages 👇🏼

so what I mean is that maybe in concept document it would be worth having 2 diagrams, one simple, and one more complex. So maybe one diagram with just one producer, and one consumer, as a kind of intro, and then another one with 2 producers, 2 consumers, and 1 producer that also is a consumer. I hope this explains more, feel free to ask for more explanation.

[quetzalliwrites]

so what I mean is that maybe in concept document it would be worth having 2 diagrams, one simple, and one more complex. So maybe one diagram with just one producer, and one consumer, as a kind of intro, and then another one with 2 producers, 2 consumers, and 1 producer that also is a consumer. I hope this explains more, feel free to ask for more explanation.

@derberg Oooooh, I mean, we can add this Flight Monitor Service diagram you made here even as an example for the 2nd more complex diagram.. right?

Yes, I agree lukasz, adding a 2nd diagram to build on the knowledge and explain more complex entities would be perfect.

@nelsonmic does that make sense for you? Do you feel good to add a 2nd diagram and explanation of it? 😀

[quetzalliwrites]

Question ✌🏽 @nelsonmic, other than adding a 2nd diagram with a written explanation of it, are you up to speed on other feedback in this PR? 😀 Do you need help with any of the feedback so far? Let us know if anything feels confusing!

I just want to sync and get a handle of where everyone is at 👍🏽

[derberg]

I'm not sure Flight Monitor Service example should be introduced here. I was rather referring to how I did it during onboarding that I showed diagram from simple to complex.

so here I suggest one diagram that says:

So maybe one diagram with just one producer, and one consumer, as a kind of intro and another: another one with 2 producers, 2 consumers, and 1 producer that also is a consumer

but without specific use case, like in case of flight service

[nelsonmic]

Hey @alequetzalli, yeah I am up to speed on the feedback provided here... I also understand what @derberg means for the second diagram, this would also mean editing the written content so i can provide more details for the second more complex diagram. I'll get to working on the draft

[quetzalliwrites]

Great @nelsonmic! Don't forget to use mermaidJS syntax in your next diagram drafts, since we have finished voting, and that tool got the most votes. 😀

[nelsonmic]

Hi @alequetzalli @derberg, I'm having some issues with my second diagram, please can you help out?

Here's the problem: When I try to use mermaid to show how a producer can also be a consumer, the producer entity goes to the other side of the broker. Maybe my syntax is wrong. Here's an image reference:

[derberg]

yeah, it is how mermaid automatically tries to scale SVG when more components are added. Mermaid does not know that for you logical is that specific component should be on the left or right. We can later try to figure these things in a website, with some custom code/css. Don't worry much about it. I suggest to maybe just remove one consumer and show it like this

flowchart LR
    a[Producer]-- Message 1 --->c[(Broker)]
    b[Producer/Consumer]-- Message 2 --->c
    c -- Message 1 ---> b
    c -- Message 2 ---> e[Consumer]

[nelsonmic]

Okay thank you, I'll revert and make another push

[github-actions[bot]]

⚡️ Lighthouse report for the changes in this PR:

Category	Score
🔴 Performance	20
🟠 Accessibility	88
🟠 Best practices	83
🟢 SEO	90
🔴 PWA	30

Lighthouse ran on https://deploy-preview-824--asyncapi-website.netlify.app/

[nelsonmic]

Hey @alequetzalli, thank you so much for the editorial review 😌, can't wait to merge. Now we just wait for @derberg technical review.

[nelsonmic]

I left some suggestions how we could simplify the wording. But I'm not an oracle, lets see what @smoya and @fmvilas think before you make changes

@smoya and @fmvilas I ping you as you were interested in other concepts docs, so maybe you'd like to share feedback here too

Alright, @derberg thank you for reviewing. I'd wait for suggestions from @smoya and @fmvilas before i make the changes.

[nelsonmic]

Hi @alequetzalli, lovely day today! I just made a commit to include the suggestions that were made by @derberg and @fmvilas, please have a look at it to see if we're good to go now.