\r\n\u003C/a>\r\n\r\n## What this would _(hopefully)_ enable \r\n\r\n> Each of these could be implemented already, but it'd likely make things quite convoluted\r\n\r\n- Procedure call batching - #273\r\n- WebSocket transport - #268\r\n- More robust subscription support\r\n- Our own query cache, as a plugin\r\n- Logging & devtools\r\n- Supplying \"retry\" links\r\n- Moving transformers to a plugin\r\n- Would make creating libs for Svelte/Vue/etc easier\r\n- Potentially, move away from relying on react-query in `@trpc/react` and make trpc lighter (unlikely to happen though)\r\n",[3221,3224,3227],{"name":3222,"color":3223},"🙋♂️ help wanted","008672",{"name":3225,"color":3226},"@trpc/client","6095C2",{"name":3228,"color":3229},"🧙🏻 typescript wizardry","391441",412,"Implement exchanges/middlewares to make client more pluggable","2022-10-05T00:09:54Z","https://github.com/trpc/trpc/issues/412",0.7001087,{"description":3236,"labels":3237,"number":3238,"owner":3173,"repository":3173,"state":3186,"title":3239,"updated_at":3240,"url":3241,"score":3242},"### Describe the feature you'd like to request\n\nI am the creator of the `trpc-uwebsockets` adapter, and I would like to implement a WebSocket core for the tRPC server. I have found issue #6109, where help was wanted for the client side. I believe that enhancements on the server side can also greatly benefit this awesome project! Here are my reasons for making this proposal:\n\nFirstly, each adapter must implement WebSocket functionality separately, currently 580 LOC for `ws` and 674 LOC for `trpc-uwebsockets`. I had to reimplement mostly everything from scratch, including copy-pasting types. v11 `ws` adapter is built around the `ws` library API.\n\nSecondly, the current implementation does weird hacks for context promise resolution. There are many edge cases leading to race conditions, which are challenging to test robustly.\n\nThirdly, the `ws` adapter creates a lot of closures and has hanging promises, which I assume are not GC-friendly. Performance could be improved, but this will need a proper benchmarking setup.\n\n### Describe the solution you'd like to see\n\nI propose that two-way communication is modeled with javascript standard `ReadableStream` and `WriteableStream`. This way, the adapters for all servers, such as `ws`, `uWebSockets.js`, `Bun`, `Cloudflare Workers`, etc., can share the same \"duplex communication glue.\" Furthermore, existing core request handlers fit nicely into this implementation, as v11 embraces `Request` and `Response` primitives. I think it's about time to modernize the WebSockets server core. Ideally, this should ship before v11 :)\n\nWhat are your thoughts on this? I can start implementing it for `ws` and `trpc-uwebsockets`. My plan is to design the API with `ws` in mind, as it is more widely used. I would like to become a maintainer once this is included in the stable core. Additionally, funding for this implementation would be much appreciated.\n\n### Describe alternate solutions\n\nCurrent `ws` implementation can be abstracted, but that would create more misdirection.\n\n### Additional information\n\n_No response_\n\n### 👨👧👦 Contributing\n\n- [x] 🙋♂️ Yes, I'd be down to file a PR implementing this feature!",[],6598,"feat: re-implement server-side websocket api.","2025-07-08T12:47:56Z","https://github.com/trpc/trpc/issues/6598",0.70108294,{"description":3244,"labels":3245,"number":3250,"owner":3173,"repository":3173,"state":3186,"title":3251,"updated_at":3252,"url":3253,"score":3254},"**👉👉👉👉 Update:** For tRPC support of public-facing APIs, please use `trpc-openapi`: https://github.com/jlalmes/trpc-openapi\r\n\r\n\r\n---\r\n\r\nIt would be nice if there was a way to easily expose tRPC-endpoints as REST (or GraphQL) for people who want to use tRPC for a public API and is a bit more intuitive. Could potentially drive adoption a bit more.\r\n\r\nSee #752 for an example of what gets confusing.\r\n\r\n... been thinking a bit about it, but it's not obvious how it could work. \r\n\r\nMaybe doing some sort of API-builder... or something where you define your API schema which then does automatic mapping to tRPC. \r\n\r\nI'm also thinking that it might not be needed - `JSON.stringify(encodeURIComponent(x))` is hard when you toy around with manual API-requests, but it's not that bad when you're actually working with the API, as it's only needed once.\r\n\r\n## Current implementation, HTTP Methods \u003C-> Type mapping\r\n\r\n| HTTP Method | Mapping | Notes |\r\n| ----------- | ----------------- | ------------------------------------------------------------------------------------------------------ |\r\n| `GET` | `.query()` | Input JSON-stringified in query param.\u003Cbr/>_e.g._ `?input=${JSON.stringify(encodeURIComponent(input))` |\r\n| `POST` | `.mutation()` | Input as post body. | \r\n\r\n## Considerations with OpenAPI\r\n\r\n- Resources are usually `/{resource}/{id}?param1=x¶m2=y`-style - tRPC is [currently] with `{resource}?input=JSON.stringify(encodeURIComponent(input))`-style\r\n- JSON-RPC based response shape might not be the ideal response shape for OpenAPI\r\n- An output schema usually have a `$ref`-schema which would be possible to do automatically / first feature people would request is to make different paths request the same input type\r\n- Actually using zod or any other validation on a resolver's `output` would slow down API outputs.\r\n\r\n## Related\r\n\r\nhttps://github.com/trpc/trpc/discussions/271\r\n",[3246,3247],{"name":3222,"color":3223},{"name":3248,"color":3249},"💬 discussion","4B318A",755,"[RFC] Using tRPC for public-facing APIs (OpenAPI/Swagger/etc)","2022-06-19T00:48:45Z","https://github.com/trpc/trpc/issues/755",0.7014346,{"description":3256,"labels":3257,"number":3261,"owner":3173,"repository":3173,"state":3186,"title":3262,"updated_at":3263,"url":3264,"score":3265},"> Also, as you're pointing out, RSC will hopefully fix this for us. I don't want to put too much more effort into `withTRPC` in it's current form as it will _hopefully_ be deprecated pretty soon (that said, for v10, we should probably make sure we have an API design that makes it tree shakable when/if that happens 😅 )\r\n>\r\n> _Originally posted by @KATT in https://github.com/trpc/trpc/issues/2625#issuecomment-1240397342_\r\n\r\n\r\nMaybe we should move the `withTRPC` to it's own `import` so it can be tree-shaken when/if [RSC](https://nextjs.org/docs/advanced-features/react-18/server-components) or the [Next.js Layouts](https://nextjs.org/blog/layouts-rfc) arrives so it can be tree-shaken as it will will likely have to be non-compatible to that API or make a bunch of stuff redundant.\r\n\r\n\r\n## Suggested change\r\n\r\n\r\n#### Before\r\n\r\n```tsx\r\n\r\n// _app.tsx\r\nimport { AppType } from 'next/dist/shared/lib/utils';\r\nimport { ReactElement, ReactNode } from 'react';\r\nimport { trpc } from '~/utils/trpc';\r\n\r\nconst MyApp: AppType = (({ Component, pageProps }) => {\r\n return \u003CComponent {...pageProps} />;\r\n})\r\n\r\nexport default trpc.withTRPC(MyApp);\r\n```\r\n\r\n#### After\r\n\r\n> Not thrilled about exactly this API-design, but gets the point across that `withTRPC()` can be tree shaken, feel free to do other suggestions\r\n\r\n```ts\r\n// _app.tsx\r\nimport { AppType } from 'next/dist/shared/lib/utils';\r\nimport { trpc } from '~/utils/trpc';\r\nimport { createTRPCNextWithTRPC } from '@trpc/next';\r\n\r\nconst MyApp: AppType = (({ Component, pageProps }) => {\r\n return \u003CComponent {...pageProps} />;\r\n})\r\n\r\nexport default createWithTRPC(trpc)(MyApp);\r\n```\r\n",[3258],{"name":3259,"color":3260},"RFC","78B062",2650,"Break out `withTRPC` from `createTRPCNext`?","2022-11-04T00:06:57Z","https://github.com/trpc/trpc/issues/2650",0.7026878,{"description":3267,"labels":3268,"number":3272,"owner":3173,"repository":3173,"state":3186,"title":3273,"updated_at":3274,"url":3275,"score":3276},"### New doc sections\r\n\r\n- **HTTP RPC Specification** -> https://trpc.io/docs/rpc\r\n- **Subscriptions / WebSockets** -> https://trpc.io/docs/subscriptions\r\n\r\n\r\nAny feedback? Feel free to modify or write here and I'll update\r\n\r\n\r\ncc @mmkal @Lilja @danielyogel @cyrus-za @peterp @anthonyshort ",[3269],{"name":3270,"color":3271},"🙏 review please","A7356F",898,"[RFC] New docs ","2022-10-04T18:08:24Z","https://github.com/trpc/trpc/issues/898",0.70277786,["Reactive",3278],{},["Set"],["ShallowReactive",3281],{"$fTRc1wZytZ_XrK4EfJfei_Sz-An4H4Yy6syhVxH_PVJc":-1,"$fw_QQGnvkKo79oBjeJSB_SBdq0M9BOUsRS2WdpxInEBg":-1},"/trpc/trpc/2338"]