feat!: move operations to its own root object #806
Conversation
fmvilas
requested review from
derberg,
dalelane and
asyncapi-bot-eve
as code owners
fmvilas
force-pushed
the
add-operations-object
branch
2 times, most recently
from
04abcc2 to
a5ac261
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
|
/progress 60 New |
|
/progress 20 did it work and regarding PR:
@fmvilas I think we just need @dalelane view on that, or are you waiting for someone else? |
? or did you make sure that only your "progress comments" are taken into account? 😄
|
/progress 60
It did work because it's meant to be used as a team so I just have to rely on the hope that you would not troll me so much 😅 (damn, as I'm writing this I'm already realizing I'm dead 😂)
Dale's point of view for sure. Would also love to have the opinions of —at least— @smoya, @char0n, and @magicmatatjahu. And of course, anyone else reading this is also welcome. I know you know but just so everyone knows :) Regarding the review, thanks! I'll address all those points 👍 |
|
Alright, I think I addressed all the points @derberg. Would you please review it again? |
| "onUserSignUp": { | ||
| "summary": "Action to sign a user up.", | ||
| "description": "A longer description", | ||
| "channel": { |
There was a problem hiding this comment.
I'm thinking that it might make sense to convert this into an array of channels (of references to channel) instead.
The use case that came to my mind was the fanout pattern, sending the same message to different channels.
For example, a user sign up action on a server might result in the server sending the same message to several queues on an EDA. Let's say those queues are owned by different departments, teams, or whatever.
WDYT?
There was a problem hiding this comment.
AFAIK, the fanout pattern is usually implemented by the broker, not the application. I mean, for instance, RabbitMQ has the fanout exchange that lets you connect various queues to a specific routingKey. Kafka, NATS, and others have consumer groups, with which you can implement the fanout pattern. The application sends a message to a particular channel and then it gets distributed to many other queues or consumers. Am I missing something?
Now, I see the value it can have by allowing us to group multiple operations into one. Batch operations if you want. We just need to be very clear that if a send operation is performed against 1 out of 3 channels and it fails, it shouldn't stop the code from sending the other 2. Aren't we getting into the land of workflow definition already? 🤔
There was a problem hiding this comment.
AFAIK, the fanout pattern is usually implemented by the broker, not the application.
This statement doesn't reflect the reality out there. The fanout could be perfectly implemented by the application; writing the same message to different Kafka topics is a completely valid use case. For logistics, you might want to set up different retention policies, permissions, etc to each topic.
Also, we can still use an AsyncAPI document to describe a message broker (wich turns to be the application), where this pattern is way more common.
At the end, a client should know where to connect to and to which channels a particular message will be sent so it can subscribe to one of those (depending on each scenario).
Aren't we getting into the land of workflow definition already?
TBH I don't think we are that far. This is still referring to an application definition.
There was a problem hiding this comment.
Yeah, that's my point. I wouldn't say it's to support fanout but to batch operations. That's a pretty valid and common use case.
@derberg @dalelane @char0n @magicmatatjahu what do you folks think?
There was a problem hiding this comment.
I don't get why it's not to support the fanout pattern but batching/grouping operations. Messages are sent in parallel to different channels.
From Wikipedia:
In message-oriented middleware solutions, fan-out is a messaging pattern used to model an information exchange that implies the delivery (or spreading) of a message to one or multiple destinations possibly in parallel, and not halting the process that executes the messaging to wait for any response to that message.
There was a problem hiding this comment.
The only use case that comes to my mind right now is auditing. Some messages will be sent to their corresponding channel + the auditing channel. But I've never seen this done in the application code. It's always configured as a rule in the broker so you don't forget to audit anything.
There was a problem hiding this comment.
The use case I had in my mind is illustrated in the following pic grabbed from Salesforce blog. In particular, I'm talking about Point-to-Point architecture (even though the name is not correct IMHO) and not entering into which one is more scalable or less because it's not the main topic being discussed here.
I still believe this is part of the application definition and still not part of defining any message flow between apps.
There was a problem hiding this comment.
but point to point is actually in contrast to EDA, right?
There was a problem hiding this comment.
but point to point is actually in contrast to EDA, right?
The name on the picture is not correct as I mentioned in my previous comment. The right name I'm looking for is EventDriven Integration, and this article from Solace explains what it is: https://solace.com/blog/event-driven-architecture-difference-event-driven-integration
There was a problem hiding this comment.
@smoya It looks like this requires its own discussion. Would you mind creating a follow-up issue? It would be great to find actual cases where this is required. Salesforce is great but I don't think it's a common use case.
🤔 Should we avoid it for now? I just want to make progress towards 3.0.0 but we're still far. Should I use |
|
tbh, I'm pro-pre-releases 😄 as they raise awareness. They will be published to asyncapi.com and will make it pretty clear to users going to "docs" that 3.0 is on the horizon. Docs is the most visited part of the website. We could add some big note at the beginning of the spec file, with some essential links on how to engage in works towards 3.0, just a thought. |
That's a good idea. Will add it. |
|
@derberg done. Let me know what you think. |
|
fmvilas
force-pushed
the
next-major-spec
branch
from
8805c88 to
624ad52
Compare
Co-authored-by: Lukasz Gornicki <lpgornicki@gmail.com>
Co-authored-by: Lukasz Gornicki <lpgornicki@gmail.com>
fmvilas
force-pushed
the
add-operations-object
branch
from
84ad14d to
9bacca4
Compare
|
Kudos, SonarCloud Quality Gate passed!
|
|
@dalelane mind having a look? |
|
/rtm |
|
🎉 This PR is included in version 3.0.0-next-major-spec.1 🎉 The release is available on GitHub release Your semantic-release bot 📦🚀 |
title: "Move operations to its own root object"
Related issue(s):
#618 #663