For larger Discord bots, the ability to proxy the gateway can be very useful for much faster restarts, by only restarting the gateway connection when absolutely necessary.
Several standalone gateway proxies do exist, and as a complete package they can be quite useful. However, there are cases where having a more bespoke solution may be ideal. The ability to receive events in plain text, from a custom process, allows rather more flexibility for things like processing, logging, and in particular choice of channel used to communicate back to the main process. For example, in my case, I take advantage of UNIX named pipes.
Unfortunately, the ability to proxy these events this way through Serenity is greatly inhibited by the lack of a way to get raw string-type events. Sending deserialized objects through any kind of communication channel is essentially impossible, and re-serializing is a large inefficiency.
As a result, it may be useful to have the ability to register a new type of event handler- MessageHandler or similar, which is like RawEventHandler, but does not deserialize the incoming event. Additionally, to accompany this, it may be useful to have a function which does this deserializing into an Event which can be used from the main process, perhaps similar to this.
I don't imagine this will be a ton of work to implement - essentially it's just splitting the steps of RawEventHandler. In any case, if I can be pointed in the right direction of where this should be done I can potentially take a crack at doing it myself, if it is a feature that may be desired.
cheesycod
commented
1 month ago
For larger Discord bots, the ability to proxy the gateway can be very useful for much faster restarts, by only restarting the gateway connection when absolutely necessary.
Several standalone gateway proxies do exist, and as a complete package they can be quite useful. However, there are cases where having a more bespoke solution may be ideal. The ability to receive events in plain text, from a custom process, allows rather more flexibility for things like processing, logging, and in particular choice of channel used to communicate back to the main process. For example, in my case, I take advantage of UNIX named pipes.
Unfortunately, the ability to proxy these events this way through Serenity is greatly inhibited by the lack of a way to get raw string-type events. Sending deserialized objects through any kind of communication channel is essentially impossible, and re-serializing is a large inefficiency.
As a result, it may be useful to have the ability to register a new type of event handler-
MessageHandleror similar, which is likeRawEventHandler, but does not deserialize the incoming event. Additionally, to accompany this, it may be useful to have a function which does this deserializing into anEventwhich can be used from the main process, perhaps similar to this.I don't imagine this will be a ton of work to implement - essentially it's just splitting the steps of
RawEventHandler. In any case, if I can be pointed in the right direction of where this should be done I can potentially take a crack at doing it myself, if it is a feature that may be desired.Thanks!