feat(client/POC): RPC support for SSE

[sor4chi]

resolve #3309

Todo

• SSE rpc handler
• FetchEvent (polyfill?)
  • LICENCE inclusion
• Typed Data interface for JSON SSE

The author should do the following, if applicable

• Add tests
• Run tests
• bun run format:fix && bun run lint:fix to format the code
• Add TSDoc/JSDoc to document the code

[sor4chi]

Hi, @yusukebe

This time, I would like to introduce Typed SSE that bypasses JSON as a feature of SSE RPC. Typed SSE is very useful, so I would like to introduce it.
Currently, the data field of SSE can specify string | Promise<string>, and the reason why it is not simply a string is that #3344 implemented by @usualoma allows Hono Stream SSE to send Hono JSX (HTML).

The problem is with the string. Most Hono Stream SSE users probably specify JSON.stringify in the data field. However, if we implement it straightforwardly, the JSON serialization and deserialization operations will be performed in the Hono RPC. Therefore, the client needs to distinguish between the JSON.stringify data and the data serialized by the RPC as Typed SSE, and we are currently exploring how to implement this while maintaining backward compatibility. If you have any good ideas, I would appreciate it if you could let me know.

[nakasyou]

The problem is with the string. Most Hono Stream SSE users probably specify JSON.stringify in the data field. However, if we implement it straightforwardly, the JSON serialization and deserialization operations will be performed in the Hono RPC. Therefore, the client needs to distinguish between the JSON.stringify data and the data serialized by the RPC as Typed SSE, and we are currently exploring how to implement this while maintaining backward compatibility. If you have any good ideas, I would appreciate it if you could let me know.

How about adding streamJSONRPC and dividing .$sse into .$sse and .$sseJSON?