Eventstorming Tool: UI to design your architecture, export to AsyncAPI file

[boyney123]

As part of our Roadmap at AsyncAPI we would like to focus on an area User is able to focus only on business logic

As part of that issue there states some scope An AsyncAPI file can be created without having to understand AsyncAPI syntax. This can be a CLI tool that asks questions, an application UI, a form, etc..

This leads me to this proposal of a new tool.

Eventstorming Tool (maybe name can change)

What is it

First, let me describe what it is and my initial ideas behind the tool.

A key part of Event-Driven Architectures is the process of identifying your events and systems (also known as Event Storming).

Events belong to anybody not just the developers or people writing the spec files/code.

Anybody on the team from any background helps with the process by defining events and flow across their application/business domain.

So this got me thinking.....

What if we had an Open Source tool that would allow people to Event Storm but rather than just boxes on the screen, they could do more with it....

What if, we could define our events, boundaries and systems and be able to add meta data, and schemas to our events and event start to map out parts of our architecture using this tool, then once you do that export into something useful.

---

Imagine the tool with these kind of features (maybe not in scope for first release ofc):

• Ability to draw events, servers, channels, subscribers and listeners
• Ability to connect them using a UI and start to map out your domain
• Ability to export the diagram into useful things (i.e your AsyncAPI file).

Why it might be useful

This hopefully could break down barriers to AsyncAPI, and allow people to collaborate using a tool and instantly get value not only from the drawing they do, but generate code and async API files etc.

How could it work

I have done a rough wireframe of some thoughts, but I'm a huge fan of https://reactflow.dev/ and I think it fits perfectly with visualizing event flows.

Here is a quick mockup of what this thing could look like:

This is something that can be run locally or maybe in the cloud.

Eventually, you could even support WebSockets and have multiple use it at the same time collaborating, but maybe out of scope...

Also done right, we could have it imported in our new studio too, that @magicmatatjahu is working on.

What's next

I would love to get some feedback on the idea, and understand if it would be useful for anyone out there.

I think there is some huge value writing some tools ontop of the AsyncAPI spec to build the AsyncAPI itself using processes we already know and do in businesses (like event storming).

Anyway, would love to know what you think.

Update (Fri 8th)

Here is a video showing the kind of stuff I think may be useful: https://asyncapi.slack.com/files/U020GN9C6FM/F02GZA0RMBQ/asyncvisual.mp4

[bobthemighty]

Have you come across event modelling at all? Your diagram looks like that might be an interesting starting point https://eventmodeling.org/posts/what-is-event-modeling/

The advantage, I guess, is that an event model also defines the data that each event should carry, by defining the use-cases that need the data.

[boyney123]

Hey @bobthemighty,

Yeah can't say I have, Thanks will give this a read and come back to you

[iamVP7]

This is interesting idea. As you mentioned it can break down lot of barriers (one of the difficult task my teammates find when writing OpenAPI spec, writing them properly; we haven't figured out any GUI tool for writing aspect).

[boyney123]

As you mentioned it can break down lot of barriers

Yeah for me I think that's the key really, focus on business stuff and have the tools aid you along the way

[smoya]

I really like the idea and I see the value in this.
Something we might want to distinguish is Event VS Message. At least afaik, In an event-driven arch, events are (or can be) represented as messages, but messages are not always events.

Something cool we could work in parallel (already talked to you about it @boyney123) is supporting event flows within the spec. In particular, the other day I started thinking about the pattern Sagas, and how they could be represented in the spec (not sure if makes sense yet).
AsyncAPI Operations that trigger some other Operations, and consecutively.

[boyney123]

Something cool we could work in parallel (already talked to you about it @boyney123) is supporting event flows within the spec

Yeah super interested in this, still fairly new to the spec, but maybe when we get some spare time we can explore this more. In theory if we can identify flow it might lead to other interesting tools etc 🤔

[siathalysedI]

I think also it would be great to identify everything related from a single saga workflow in the spec

[smoya]

Thanks to @jessemenning, TIL about https://serverlessworkflow.io, which basically let's you define all the workflow states and the actions to transition between states. They also have support for AsyncAPI Operations.
This is an example based on AsyncAPI Streetlights (short version) that emulates an RPC action that gets a light measure, and then publishes in the channel described in the AsyncAPI file: https://gist.github.com/smoya/d382fb29f3497319e4927cf998b8d5dd

[magicmatatjahu]

Interesting idea. I agree with the previous speakers and I have mostly the same opinion, but I would just like to show you a tool (or rather a plugin) - https://github.com/dalelane/node-red-contrib-plugin-asyncapi - created by our one of the most active contributors @dalelane. It is not what we think (building/updating spec by nodes), but it is very similar, on which we could base.

[boyney123]

Yeah thanks @magicmatatjahu will take a look at that looks nice

[jessemenning]

I think it's a valuable idea. On the commercial side, Solace has Event Portal, which has much of this functionality.

[boyney123]

Cool! @jessemenning do you work at Solace? Would love a showcase/demo at some point of the system, would be pretty interesting to see things in action

[boyney123]

I made a video of an idea here: https://asyncapi.slack.com/files/U020GN9C6FM/F02GZA0RMBQ/asyncvisual.mp4

[smoya]

It looks awesome @boyney123 ! 👏

I see this can become a great tool that could let us arrive to more users, to smooth the learning curve.
Something that came to my mind when watching the video was how cool will look for channels assigned to servers (AsyncAPI spec >= 2.2.0) - asyncapi/spec#531

[siathalysedI]

I think we need to start talking about event storming as is the baseline for this. And to start relating our documentation then into the event storming workshop practices. I can help the team to make the event storming. I don't know if I should open another discussion but I think it would be great start to including it as part of our workflow so we can have a broader scope

[smoya]

Hi @intfrr!

I can help the team to make the event storming

I think I didn't get what you mean. Are you referring to do an event storming session? If so, isn't that a technique that final users (individuals, teams, etc) should do? This will be one of the tools they could use.

[InfoSec812]

@boyney123 I would love to see a tool for doing Event Storming and generate an AsyncAPI from it. I am an avid user of APICurio.io and it allows you to do some similar things with OpenAPI. For example, you can paste in an example JSON Body and have it create the JSONSchema and related CRUD REST API endpoints.

[InfoSec812]

BTW, you can see a demonstration of the APICurio JSON -> OpenAPI here: https://youtu.be/byXzRsh5TXE

[boyney123]

Thanks @InfoSec812

Yeah I love the idea of generating the schema from example JSON, as you said during the process of defining and discovering our events, I think its easier to express them in JSON vs straight to schema. Will keep this in mind.

[derberg]

The coolest thing would be if this can work in both directions. I mean I can model my system in the UI and export AsyncAPI files, but also I can actually write AsyncAPI files and then import them into the UI and get the visualization. So we support both, new users, and folks that are already here and went through hell of creating AsyncAPI files by hand 😆

https://github.com/asyncapi/cupid/ is a project that can generate React flow diagrams and others by analyzing AsyncAPI documents. I think there is value in aligning both projects

[InfoSec812]

That would be nice, but I have to wonder if there is sufficient information in an AsyncAPI Spec to fully populate an EventStorm? EventStorms have a lot of information beyond what is contained in AsyncAPI specification files. Things like Actors, Commands, UIs, Views... I'm not sure we could put enough information comfortably into the spec file without making it less readable for it's purpose.

[derberg]

It would just show a "limited" view of the relations between different apps and the communication channels. Then we can go further and think if it makes sense to extend AsyncAPI spec or just have EventStorm related extensions in the extensions catalog

[boyney123]

Love the ideas @derberg, the import/export feature would be great.

I'm going to get an initial application together that allows us to import/export asyncapi files, create events (pub/sub operations) and application stuff to get some feedback.

From that we can explore other EventStorming stuff and see how the application can evolve with feedback.

Some great ideas!

[boyney123]

Thanks everyone for the feedback so far, next steps for me will be:

• Creating a new project (for now) that will allow us to create asyncapi files and see them
• Ability to import/export to AsyncAPI files
• Documents on how to contribute etc.

I'm thinking for now having this as a standalone application you can run on your machine, but with the future view to allow this to be injected/used within the AsyncAPI studio (and other applications too).

I will share something back with this group when I get something working for it's initial feedback and next steps.

Thanks!

[boyney123]

Just an update here,

I managed to get something working and also it has been added to our new version of the AsyncAPI Studio (which is currently on this branch)

If you want to give it ago you can check out the branch and then load your AsyncAPI file and see how it looks.

Next steps, is to get Studio live and start to get feedback around the tooling and take it from there.

[aschrijver]

I find the ideas discussed in this thread to be very interesting. In my opinion going this direction would be a real enrichment to what AsyncAPI has to offer. Looking through the website and examples I see mostly the 'typical' message queuing use cases addressed, with channels, topics, pubsubs, etc. And kind of fixed infrastructures, server topologies.

My interests not only go to DDD, CQRS/ES but also abilities to describe message exchanges for federated protocols. I am referring here to ActivityStreams and ActivityPub W3C recommendations. ActivityPub is an email-like protocol with inboxes and outboxes where messages between Actors are exchanged (i.e. a sort of distributed Actor Model). Based on ActivityStreams as a core ontology with social networking primitives, vocabulary extensions can be written and defined as JSON-LD Linked Data. The AS/AP protocol stack is what drives the Fediverse.

On the topic of Event Storming in particular I found this conference talk by @mattbishop to be quite interesting: https://www.youtube.com/watch?v=_JPcWvioBM8

One question I have.. this discussion is more than a year old, and related discussion #221 also wasn't given follow-up (at least in that location). Are there reasons for that? Like focussing on different areas with AsyncAPI first?