Define a better API that can be used by other applications
Opened this issue · 5 comments
Current API is just a websocket server where validation errors are being published.
This is now ok since we are just on a very early development stage, however in the future integrations with other tools are a possibility.
For example, https://github.com/asyncapi/studio could call read from this API and get suggestions on changes to apply to schemas.
Hey @smoya
We spoke yesterday about the API / Websocket, and maybe it would be good to include (if we can) the client that made the request in the payload to the websocket.
When I visually see the event-gateway, it would be interesting (as you said above) to have some applications consume the API / WebSocket.
Be awesome ( I think ) to have an application that can run alongside the gateway (optional docker container) that consumes and visualises the WebSocket stuff in real time.
Things I think might be useful (in this app):
- Seeing the events fly through the event gateway (maybe client + name of the event)
- Seeing any validation errors with events as they come through (maybe some sort of alerting too)
- Seeing any events that are filtered (validation but more filter, like the event should not be there / is not documented).
There is something awesome about visuallising events in real-time I think it's perfect for this API.
Guess it would be good to define an API contract... 🤔
Hi @smoya and @boyney123 😃, having this API would be awesome!
I'm not very familiar with this project so I don't know what is best for the API contract, but since there are many events coming to the gateway, each one will have its schema right? Maybe the contract would be open-ended for some cases and be specific on others. Meaning apps could consume an object that could have many fields, but if there is a Content-Type header on the WebSocket message, then the app knows how to parse the event and understand its schema.
Other use cases for this API are emitting events to the WebSocket connections letting apps know when the gateway received an event, and when it was dispatched to the various handlers (e.g. Kafka). This is useful for monitoring purposes.
Be awesome ( I think ) to have an application that can run alongside the gateway (optional docker container) that consumes and visualises the WebSocket stuff in real time.
In regards to this app that could consume the API of Event Gateway, would it be similar to the Visualiser used in Studio? For some reason this statement "Seeing the events fly through the event gateway (maybe client + name of the event)" reminded me of Visualiser and I actually thought this was already implemented 😅 .
Also, does it make sense to have more than one API in the Event Gateway? Perhaps we can have a Websocket and an HTTP interface, each integration we would want to do uses the most appropriate choice.
Let me know your thoughts 👍
is it really considered as a good first issue ?
You don't need AsyncAPI knowledge and by defining a better API will mean doing iteratively. Anything better than what we have now will improve the API, an API no one depends yet.
I agree it is a bit in the middle and it can be hard to understand, so I'm happy to remove the label anyway 👍 @derberg .
This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.
There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.
Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.
Thank you for your patience ❤️