Recommended way to emit from outside a socket context (e.g. from express-zod-api HTTP handlers)?

[giovio]

Hi, and thanks for both zod-sockets and express-zod-api — using them together.

My use case: the socket is a push-only channel. All mutations happen over the REST layer (express-zod-api), and after a successful mutation I want to emit a typed event to a room (e.g. emitBusiness(id, "updateRequest", dto)). I never receive events from clients — no Actions, no RPC.

What I found:

The express-zod-api integration section covers sharing the same HTTP server (attachSockets({ target: servers.pop()! })), but not how to emit from an HTTP handler.
The only way to get an emitter outside a client event seems to be capturing the IndependentContext in the onStartup hook (the docs' example is a setInterval). So I stash that context in a singleton and expose emitUser / emitBusiness wrappers over withRooms().broadcast().
IndependentContext isn't exported, so to type the stashed value I derive Omit<ClientContext<E, D>, "client">.
Questions:

1. Is capturing onStartup's context the intended pattern for "emit from elsewhere in the app", or is there a blessed API I've missed?
2. Would you consider exposing a standalone emitter — e.g. a createEmitter(config) factory, or the IndependentContext returned from attachSockets() — so it can be imported directly into HTTP handlers without the onStartup dance?
3. If not, would you at least export IndependentContext so it can be typed without the Omit<ClientContext, "client"> workaround?

[RobinTail]

Hello, @giovio

For what you've described I'd also suggest to consider a bit simpler SSE approach that is available in Express Zod API:
https://ez.robintail.cz/v28.7.5/subscriptions
Doing that, you'd only have to maintain the "room" of those to notify.

Regarding your questions:

Is capturing onStartup's context the intended pattern for "emit from elsewhere in the app", or is there a blessed API I've missed?

It was not supposed to "emit elsewhere in your app". For the cases like this, the idea was to keep the emission inside the onStartup hook while also interacting with other parts of the application via an EventEmitter or similar. Your Express Zod API endpoint could emit an internal event that would trigger the emission inside the loop of the onStartup hook.
I consider taking entities out of their scope an anti-pattern, except maybe try..catch blocks and in rare cases — Promises, but they fixed that problem recently.

Would you consider exposing a standalone emitter — e.g. a createEmitter(config) factory, or the IndependentContext returned from attachSockets() — so it can be imported directly into HTTP handlers without the onStartup dance?

I like the second suggestion (returning it from the attachSockets(). That, however, would be a breaking change, so I'd have to make a next major version for that. I will make a note for myself. Meanwhile you can fork.

If not, would you at least export IndependentContext so it can be typed without the Omit<ClientContext, "client"> workaround?

I'd prefer to avoid that due to the everything said above and because that the interface is generic.