(Optional) Integration with the Event Gateway

[boyney123]

Reason/Context

We still have the Event Gateway in development, and I was speaking to @smoya a couple of weeks ago, and I believe the gateway will/does provide a websocket url.

I believe the Gateway acts like a middle man between events and brokers (at the moment only supports Kafka). The WebSocket is used to pass any key information to anybody that wants to listen (validation issues etc).

I think it might be nice if the Studio supported integration into this WebSocket?

Maybe as an optional feature (for example if the ENV var is set for the feature/websocket url) then the feature can be there.

What will the feature do

I guess it really depends on the contract from the event-gateway, but it can be used to help people see any validation issues they may have, payloads going across systems etc......

(We would have to explore this more).

But I believe a tool that consumes this WebSocket URL would be great.....

Alternative

We don't put it in the studio but just have another application that's sole purpose is the event-gateway-WebSocket listener or something.

---

Would love to know your initial thoughts? @magicmatatjahu @smoya

[smoya]

Indeed the Event-Gateway has an API. Currently, it only has one WebSocket endpoint where validation errors flow, but as the state is under development, we didn't take it so seriously yet.
However, an issue was opened weeks ago as a placeholder for designing a proper API that will be available for interacting with the app. asyncapi-archived-repos/event-gateway#47

Some features I see we could implement are:

• Create all configurations for the Event-Gateway through the Studio. That translates into modifying interactively the AsyncAPI file, adding configuration for the Proxies if needed, etc.
• Display message validation errors in a nice way. Maybe with interaction like "what do you wanna do with those messages from now on?, (i.e. discard them, fix them, etc".
• Real-time event flow. Display all or some (a summary?) of the messages that are flowing through the app. Adding a filter based on schema, etc.
• Etc

One of the main questions we have to solve is the one you @boyney123 kinda mentioned in the alternative section:

Does it make sense to use Studio as the UI for the Event-Gateway? As it can grow a lot in terms of features, maybe we can end up mixing things, making Studio have some logic that are not used for most of users, especially because most users of the Studio won't need anything from the Event-Gateway.

[boyney123]

Thanks @smoya

Does it make sense to use Studio as the UI for the Event-Gateway? As it can grow a lot in terms of features, maybe we can end up mixing things, making Studio have some logic that are not used for most of users, especially because most users of the Studio won't need anything from the Event-Gateway.

Yeah hmm, think my gut feel is maybe the Studio should not be responsible for this (yet anyway). Guess adding this code to Studio might bloat the code base for like < 5% of users (I'm only guessing here). Guess Studio is designed anyway from any protocol and also more of a design / doc tool.

More I think about it, I think we should have another app that can sit along side the event-gateway

[smoya]

More I think about it, I think we should have another app that can sit along side the event-gateway

I think so as well.

[magicmatatjahu]

We can always treat the event gateway view/app as a module for the studio, or a microfrontend if it is a new application. I do not see a problem, but I agree that it should not be a part of the Studio's codebase.

[boyney123]

Cool, I'm going to close this issue for now on the Studio and we can use asyncapi-archived-repos/event-gateway#47 going forward.