Currently our event system is only webhook based, this means a user needs to register a callback url for a specific event and if this event occurs we send a POST request to this endpoint. We should think about adding support for server sent events, so that a client can register and listen live for those events s.
https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
This means we would need an url i.e. like /system/listener/:event_name and a user could use this as EventSource.
Implementation
To implement this we need two tables, the first table fusio_sse_listener where we create an entry if a user starts listening for an event (we also directly remove the entry if a user aborts the connection). Then we need another table where the actual events are inserted fusio_sse_data, the listener endpoint then checks every second this table and returns new entries for a specific event and it also directly deletes those entries.
On the other side we need an message queue handler which inserts the event data into this table, basically like the current webhook listener. We check whether we have a listener for a specific event and only insert the data in case a listener is available.
Currently our event system is only webhook based, this means a user needs to register a callback url for a specific event and if this event occurs we send a POST request to this endpoint. We should think about adding support for server sent events, so that a client can register and listen live for those events s. https://developer.mozilla.org/en-US/docs/Web/API/Server-sent_events/Using_server-sent_events
This means we would need an url i.e. like
/system/listener/:event_name
and a user could use this asEventSource
.Implementation
To implement this we need two tables, the first table
fusio_sse_listener
where we create an entry if a user starts listening for an event (we also directly remove the entry if a user aborts the connection). Then we need another table where the actual events are insertedfusio_sse_data
, the listener endpoint then checks every second this table and returns new entries for a specific event and it also directly deletes those entries.On the other side we need an message queue handler which inserts the event data into this table, basically like the current webhook listener. We check whether we have a listener for a specific event and only insert the data in case a listener is available.