I imagine you could write a custom tRPC link to send the data over something like MQTT which may be better for an embedded client - there's prior art in the likes of electron-trpc, showing how tRPC could be adapted to non-HTTP transports. Not sure how that interacts with the JSON-RPC bits of the subscription protocol though, if there's no way around it then plain MQTT may be better suited to your use case.
Thank you for the suggestions! I am specifically looking to optimize frontend-to-server communication, so WebSocket is a must. Is there some way I could inject a custom transform function between TRPC and the WebSocket? I could copy the existing WebSocket link and add my transform in there, but it would of course be easier if I could just do my own wire handling with the existing code.
Essentially I'd like to inject a custom respond[0] encoder and a custom parseMessage[1] decoder, and same for the client.
Update: I was able to get this working by wrapping WebSocket and WebSocketServer! The API surface for the wrapper seems to be pretty minimal. If I do use TRPC in the rewrite of the embedded server, I'll implement a custom message scheme as an alternative and benchmark them.
I will add wrappers for WebSocket/WebSocketServer in the future to allow using this without the library having to support it, like in the PoC with trpc.
