Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adding support for middlewares intercepting outgoing events #4885

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

NyaStone
Copy link

@NyaStone NyaStone commented Nov 30, 2023

The kind of change this PR does introduce

  • a bug fix
  • a new feature
  • an update to the documentation
  • a code change that improves performance
  • other

Current behavior

Currently middlewares are limited to hook before the server aknowledges a clients message, but it can't hook on the client acknowledging from the client.
Currently data validation logic needs to be rewritten in the logic of every emited with acknowledgements, that may result in a lot of boiler plate code.

New behavior

Introduced the useOutgoing((event: [string, ...any[]], next: (err?: Error) => void) => void) method.
It is behaving much like regular use() does, but before the messages are being sent from the server to the client.
(They do run before the catch all listeners and before the acknowledgement callback gets popped to the ack manager in order to be able to edit the event, or abort it).

Example:

io.on("connection", (socket) => {
    socket.useOutgoing((event, next) => {
      if (event.length && typeof event[event.length - 1] === 'function') {
        const callback = event[event.length - 1];
        event[event.length - 1] = (...args) => {
          // able to hook right before the acknowledgement callback is executed.
          callback(...args);
        }
      }
      // do not forget to call next
      next();
    });
});

Other information (e.g. related issues)

I disscussed other option briefly in this issue #4882.
For short, the tricky part about this, is that one might want access to the context of the event that originated the ack repsonse whilst consuming what the client acknowledged. Else it would be of no use hooking there, except for logging purposes I guess.
This would be a solution that doesn't disrupt current usage of Socket.IO, and we have access to the context of the event.

@bperel
Copy link

bperel commented Dec 18, 2023

Is this PR basically allowing to add event emit interceptors? It could be a great way to allow acknowledgement caching, in the same way that axios-cache-interceptor does it for Axios requests :-)

@NyaStone
Copy link
Author

Is this PR basically allowing to add event emit interceptors? It could be a great way to allow acknowledgement caching, in the same way that axios-cache-interceptor does it for Axios requests :-)

I haven't played with axios around yet. But from what I read from the axios-cache-interceptor docs the idea of this PR is similar to the interceptors, even tho the implementation varies a little bit. I based my implementation on the socket.io socket middlewares implementation so it works the same (unlike axios cache interceptors where inbound interceptors are FILO and outblound are FIFO).
The main point stands of being able to hook into and filter properly in and outbound requests is the same.

@NyaStone NyaStone changed the title Adding support to add middlewares on emitted events Adding support for middlewares intercepting outgoing events Dec 22, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants