🚀 Road to oRPC v2: Call for Ideas, Features & Feedback #1293
Replies: 57 comments 115 replies
-
|
attaching errors to middleware please - if i have auth middleware that may throw a 403, using the middleware should attach that error. |
Beta Was this translation helpful? Give feedback.
-
|
ready in v2. |
Beta Was this translation helpful? Give feedback.
-
|
I'd like to be able to return a Response from a handler, making |
Beta Was this translation helpful? Give feedback.
-
|
Related: #1058 |
Beta Was this translation helpful? Give feedback.
-
|
So much this. It's the only thing that forces me to have my HTTP handlers in two places: ORPC and the web framework. |
Beta Was this translation helpful? Give feedback.
-
|
also related: https://github.com/unnoq/orpc/issues/954 |
Beta Was this translation helpful? Give feedback.
-
|
v2 support returning |
Beta Was this translation helpful? Give feedback.
-
|
Stabilize ArkTypeToJsonSchemaConverter. |
Beta Was this translation helpful? Give feedback.
-
|
ready in v2. |
Beta Was this translation helpful? Give feedback.
-
|
Overall the thing is struggle most with are Typescript errors when I have lots of middlewares used in different combination. Not sure how it can be improved though. Would also be very nice to be able to define middlewares that transform regular output into eventIterator. So we can have a liveQuery middleware for example, that calls the handler when a Publisher emits something, and the handler is a regular function (not a generator). |
Beta Was this translation helpful? Give feedback.
-
|
I know it’s complicated, but it would be amazing if OpenAPI output schema could be determined dynamically inferred on the return type of the handler |
Beta Was this translation helpful? Give feedback.
-
You are right in the fact that elysiajs do infact achieve this, But this is not runtime agnostic as this requires to statically analyse the source files, which may not be available even on the compatible runtimes. Source. oRPC is not a framework, this would be outside its scope. I believe a thirdparty/external tools should be used instead. Should your compiled code be reading your source code files at runtime, No. |
Beta Was this translation helpful? Give feedback.
-
The spec generation is not meant to be run in the browser, instead, Scalar/Swagger web UI calls for example
Call it however you want, that's only words. Even React, call themselves a library and not a framework (and consider that Next.js, TanStack Start, Remix are the "frameworks" of React), but one could argue, that React is itself a framework. Ideally, we could use oRPC with the Node.js builtin http:server to do everything, and that's it, no need to use Fastify, Nest.js, H3, Hono or whatever "framework" on top of it. oRPC is sufficient by itself with I don't understand why it would be out of the scope of oRPC. It would be very convenient to use
Personally, I'm not compiling/transpiling my Node.js server code, but use the builtin Type Stripping from Node.js: https://nodejs.org/docs/latest/api/typescript.html (which is transpile at runtime to remove types specifier, to be able to execute the code). "at runtime", as said, it's not necessarily a thing at runtime, the |
Beta Was this translation helpful? Give feedback.
-
I disagree, it could easily just be another package under
Yeah the schema generation would have to be done before compilation. After compilation was never a goal here (and impossible) If I have free time I wouldn't mind making a package for this. I was thinking of potentially modifying the way the openapi schema generator works but I'd have to look into it |
Beta Was this translation helpful? Give feedback.
-
oRPC explicitly advertises multi-runtime support, https://orpc.dev/#:~:text=Multi%2DRuntime%20Support. By requiring the
React is a library, libraries help you accomplish a couple tasks; frameworks define your whole project.
A long side what unnoq mentioned in their comment to your issue, oRPC is a library and should not require a build step. Statically analysing then generating a openapi.json file is another build step required in a CI/CD pipeline, and CI/CD already takes enough time. Now you could skip the build step and generate the spec at runtime on each request but it would as i mentioned early have to read your source typescript code to generate the spec costing more Disk Reads + CPU Time. But not all projects will have the source typescript files available, consider a Typescript application compiled to NodeJS JavaScript and then packed into a docker image; You have the
Not everyone is doing this. Personally I'm compiling/transpiling my Node.js server code. |
Beta Was this translation helpful? Give feedback.
-
Major oRPC features i would expect to be aligned with oRPC values such as Agnostic Runtime Support as its one of the Selling points of oRPC.
While I understand generating the OpenAPI spec at build time (pre-compilation) might seem feasible, oRPC is fundamentally a runtime library, not a codegen tool; Requiring a separate build step I believe goes against its design principles. Don't get me wrong, I'm not against inferring types to generate a OpenAPI spec, but I'm against the current methods that are being used, they come with many limitations, disadvantages and of course more build steps. |
Beta Was this translation helpful? Give feedback.
-
|
Its a small thing. But I think this const server = createServer(async (req, res) => {
const result = await handler.handle(req, res, {
...options
})
if (!result.matched) {
res.statusCode = 404
res.end()
}
})could be simplified to this because the 404 part is probably the same for everyone. So the only reason we need code within the req-res-callback is to set options for the handler - which could also be set on the server. Less code means its more easy to understand and easier for newcomers. |
Beta Was this translation helpful? Give feedback.
-
|
But what if you have multi handlers? I think current approach make oRPC easy to embed to any existing framework. |
Beta Was this translation helpful? Give feedback.
-
|
Oh I forgot that you can do this as I only have one handler. Yeah, then it doesn't make sense. |
Beta Was this translation helpful? Give feedback.
-
|
codegen. types generation to use in frontend props. |
Beta Was this translation helpful? Give feedback.
-
|
You can just use InferClientOutputs https://orpc.dev/docs/client/client-side#infer-client-outputs |
Beta Was this translation helpful? Give feedback.
-
|
Easy integration with message brokers such as Nats.io, RabbitMQ, etc. For now, I have implemented a custom Link/Handler for Nats.io, but it's a bit tricky with ServerPeer to transfer native messages. |
Beta Was this translation helpful? Give feedback.
-
|
Can you share more detail, how it can improve? |
Beta Was this translation helpful? Give feedback.
-
|
Documented support for tanstack AI. |
Beta Was this translation helpful? Give feedback.
-
|
nice-grpc has a great feature that you can set retries and timeouts on the client and the rpc call. Setting defaults on the client is a nice feature as you don't have to remember to do it on every invocation. const client = createORPCClient(new OpenAPILink(contract, { url: '...' }, {
retries: {
planet: {
list: 3,
find: 3,
create: 1,
}
},
timeouts: {
planet: {
list: 1_000,
find: 1_000,
create: 5_000,
}
},
});This could use the contract and ensure you're only setting retries/timeouts for registered rpc calls. |
Beta Was this translation helpful? Give feedback.
-
|
been trying to combine vercel resumable-stream with oRPC 👀 |
Beta Was this translation helpful? Give feedback.
-
|
What about this by increase exp date to 24h for example: https://orpc.dev/docs/helpers/publisher |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Here my example: https://github.com/unnoq/orpc-resumable-stream |
Beta Was this translation helpful? Give feedback.
-
|
It would be great to have explicit separation between queries and mutations in procedure definitions, similar to tRPC’s approach. Currently, the inferred oRPC client doesn’t distinguish between query and mutation procedures, which means queries could be exported as mutations and vice versa.
I feel that the current recommandation with a filter on keywords in the client definition isn't ideal |
Beta Was this translation helpful? Give feedback.
-
|
That's something that I much prefer on oRPC compared to tRPC to be honest. Always disliked how in tRPC subscriptions were this special thing that needed special React hooks to consume. In oRPC, regular handler + useQuery + a helper function, almost totally transparent. You can also do this: import { userQueries, userMutations } from "./user.ts"
import { todoQueries, todoMutations } from "./todo.ts"
const router = {
query: {
user: userQueries,
todo: todoQueries
},
mutation: {
user: userMutations,
todo: todoMutations
}
} |
Beta Was this translation helpful? Give feedback.
-
|
First-class support for usage without the server part, clearly described in docs. Including request and response validation on the client :) I think you kinda can do that now already? But that's my use case as I want to migrate away from dead zodios. |
Beta Was this translation helpful? Give feedback.
-
|
Yes it is possible now, |
Beta Was this translation helpful? Give feedback.
-
|
be able to easily generate a client for external consumption without depending on anything from the server (maybe this already exists and i don't know about it ?). e.g., my |
Beta Was this translation helpful? Give feedback.
-
|
Contract-first approach can help you deal with this problem: https://orpc.dev/docs/contract-first/define-contract |
Beta Was this translation helpful? Give feedback.
-
|
Maybe a logger plugin, which can also be used in serverless environments like cf workers. As far as I know, the current "Pino Integration" doesn't work for Cloudflare Workers. |
Beta Was this translation helpful? Give feedback.
-
|
i'm using orpc pino integration in Google Cloud Run, which is another serverless environment, I had to use |
Beta Was this translation helpful? Give feedback.
-
|
I'd vote for a more abstract logger, for example, ours is a wrapper over winston with open telemetry things added in. I would be nice to be able to use it if oRPC just asks for a LoggerInterface that we must conform to |
Beta Was this translation helpful? Give feedback.
-
|
@ValentinGurkov Actually oRPC only rely on pino interface, you can you any logger that satisfy that interface. Or is there any standard-logger library? |
Beta Was this translation helpful? Give feedback.
-
|
@unnoq well, the docs state that we need to import things from |
Beta Was this translation helpful? Give feedback.
-
|
v2 will support evlog.dev - edge ready. |
Beta Was this translation helpful? Give feedback.
-
|
https://www.evlog.dev/ support |
Beta Was this translation helpful? Give feedback.
-
|
Do we need any special built-in support? I think we can already handle evlog with the current plugin/middleware system. |
Beta Was this translation helpful? Give feedback.
-
|
I think it would be great to have at least an example on how we could integrate both in orpc and evlog docs (more exposability to orpc too). |
Beta Was this translation helpful? Give feedback.
-
|
v2 will support evlog |
Beta Was this translation helpful? Give feedback.
-
|
My oRPC v2 wishlist:
It mostly revolves around websocket stuff because my React Native mobile app leverages websockets heavily and benefits from having all of this functionality baked in. I'm very impressed with v1 so I'm excited to see v2 soon 😃 |
Beta Was this translation helpful? Give feedback.
-
Maybe we could develop a lighter version of Partysocket - enough for oRPC - while keeping current API.
In v2, the websocket option can be an async function, which enables lazy mode. (v1 can too but I'm too lazy)
There is already a |
Beta Was this translation helpful? Give feedback.
-
v2 will be easier to override serializer - should we can create a dedicated for react native? |
Beta Was this translation helpful? Give feedback.
-
|
Ignore what I said about React Native support for file uploads. Expo just changed the default Excited for v2! Keep up the grind |
Beta Was this translation helpful? Give feedback.
-
|
I'm thinking about provide built-in re-connection for websocket. Should I enable it by default? @bnussman |
Beta Was this translation helpful? Give feedback.
-
|
Great question... It would be fine if was opt-in as opposed to enabled by default. I expect everyone has different requirements and opinions about how and how often the client should try to reconnect. With that said, I have no objection to it being enabled by default, as long as it is customizable in some way via a retryDely value or function or something like that. |
Beta Was this translation helpful? Give feedback.
-
|
I'm not sure whether this is already possible (at least its not mentioned anywhere) but for ORPC v2 it would be cool to have a possibility to disable validation in favor of performance in production without disabling transformations of e.g. dates. |
Beta Was this translation helpful? Give feedback.
-
|
Can you explain more about "without disabling transformations of e.g. dates."? |
Beta Was this translation helpful? Give feedback.
-
|
Validation libraries like This validation and transformation is not for free and will cause APIs to be slower because of it, but in production one could argue that the validation could be skipped while the transformation part still needs to run so the data-types are correct. In The goal would not be to strictly split them, but the be able to skip the validation without skipping the transformation |
Beta Was this translation helpful? Give feedback.
-
|
@dinwwwh do you have thoughts about this? |
Beta Was this translation helpful? Give feedback.
-
|
|
Beta Was this translation helpful? Give feedback.
-
|
If you don't know you can completely disable input/output validation with plugin. |
Beta Was this translation helpful? Give feedback.
-
|
Support for the Temporal API for date, datetime and duration would be great in v2 :) |
Beta Was this translation helpful? Give feedback.
-
|
It would be great to have a built‑in RPC playground, independent of OpenAPI—similar to GraphiQL, but for RPC. We could explore and invoke procedures directly in the browser, with inputs, outputs, and auto‑complete, all driven by the oRPC contract. No OpenAPI generation, Postman, or external tools are required. |
Beta Was this translation helpful? Give feedback.
-
|
I guess the main one for me at the moment as I'm migrating to Effect, is defining the key points where oRPC holds an advantage over Effect's primitives for networking, errors, and typing. I understand there's so many useful features in oRPC, but there's also so much overlap that it's hard to justify using both. For those of us using Effect:
I'm not that deep into the migration yet, but because there's so much overlap, I'm wondering if you would still recommend oRPC over Effect RPC/HTTP, Schema, etc. Would love to hear your detailed perspective here. Thank you! |
Beta Was this translation helpful? Give feedback.
-
|
oRPC v2 will provide a simple Effect integration.
I don't have a strong answer for that yet - feel free to try both and see which fits your needs better. That said, I believe oRPC is currently one of the most feature-complete RPC libraries available, with many capabilities that Effect RPC/HTTP doesn't provide today. |
Beta Was this translation helpful? Give feedback.
-
|
Static file server helper function. Something like: os.handler(fileServerHandler('./public'))Hono has similart helper function |
Beta Was this translation helpful? Give feedback.
-
|
This would be incredibly useful. I would use it in all my oRPC projects. |
Beta Was this translation helpful? Give feedback.
-
|
I think that will work too. Not sure which one is better. |
Beta Was this translation helpful? Give feedback.
-
|
I think this falls under the responsibility of the adapter you're using, as in your Hono example. |
Beta Was this translation helpful? Give feedback.
-
|
@nghiepdev It's similar to the CORS or compression plugins: a common enough use case that I think oRPC should support it directly. Not every use case needs to be built in, but for most common scenarios, users shouldn't have to reach for a third-party library like Hono. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah exactly, I'm not even using Hono, I'm just using node http, and without this I have to add another third party package or write it myself. |
Beta Was this translation helpful? Give feedback.
-
|
One niche utility that would be nice is a helper to create these generic client-side proxies like the one returned by createTanstackQueryUtils. Would be helpful for custom TanStack Db integration, but could be used for more than that. |
Beta Was this translation helpful? Give feedback.
-
|
Client links should also accept relative paths instead of full URL. Different hosts can call the API and I want the keep the original host. const link = new OpenAPILink(contract, {
url: `/api`,
}); |
Beta Was this translation helpful? Give feedback.
-
|
Already support in v2. |
Beta Was this translation helpful? Give feedback.
-
|
OpenAPI 3.2 support? Finally we have nested tags in 3.2. |
Beta Was this translation helpful? Give feedback.
-
|
Support for describing parameters in cookies. I created dedicated MR for v1: #1582 |
Beta Was this translation helpful? Give feedback.
-
|
One improvement which could be introduced in const updatePlanet = os
.meta(openapi({
method: 'POST',
path: '/planets/{id}',
inputStructure: 'detailed',
}))
// input is a raw object instead of z.object({})
.input({
params: z.object({ id: z.string() }),
query: z.object({ dryRun: z.coerce.boolean().optional() }).optional(),
headers: z.object({ 'x-trace-id': z.string() }).optional(),
body: z.object({ name: z.string() }),
});With that, the |
Beta Was this translation helpful? Give feedback.
-
|
This is planned, but I'm not sure it will make it into v2. I'm considering introducing a new extension, |
Beta Was this translation helpful? Give feedback.
-
|
🎂 It's my birthday today, and I have a gift for you: oRPC v2 is now in open beta 🚀 https://v2.orpc.dev/ |
Beta Was this translation helpful? Give feedback.
-
|
Happy birthday!!! 🍰 |
Beta Was this translation helpful? Give feedback.
-
|
Happy birthday brother! Super excited for v2. Looks amazing so far |
Beta Was this translation helpful? Give feedback.
-
|
Happy Birthday! :) (Today is also my birthday and I appreciate the nice gift!) |
Beta Was this translation helpful? Give feedback.
-
|
Proposal: server-initiated RPC over WebSocket in v2 (a callable client router) To be precise up front: oRPC's WS is already full-duplex for data flow — within a client-initiated call the server streams back fine (event iterators, octet streams). The gap is server-originated requests: the server cannot start a new typed call to a specific connected client, because there's no client-hosted router for it to target. This is baked into the v2 peer protocol: Since v2 is already reworking the WS layer (lazy mode, reconnection, Proposal — let the client expose a router the server can call:
// client — declare what the server may call on us
const link = new RPCLink({ websocket, router: clientRouter })
// server — initiate a typed call to a specific connection
handler.onConnection(async (conn) => {
await conn.client.toast({ message: "saved" }) // typed against clientRouter
})Notes
|
Beta Was this translation helpful? Give feedback.
-
|
I don't understand the reasoning behind this. If you just want to show a toast, why not add an Also, |
Beta Was this translation helpful? Give feedback.
-
|
I understand there are technical reasons for replacing Perhaps it would be an option to add shortcuts for the standard behavior as implemented in v1, at least for the OpenAPI/route definition? Thanks for your commitment to this great library! |
Beta Was this translation helpful? Give feedback.
-
|
Or perhaps an even better option would be to make the "meta plugins" extends the builder, so you could do or |
Beta Was this translation helpful? Give feedback.
-
Personally, I see it as just metadata - it has no special meaning by default until something interprets it. If it's read by OpenAPIHandler/Link, it becomes routing info. If it's read by RPCHandler/Link, it has no effect at all. The same applies to custom metadata in general. As for your proposed approach - it looks nice, but I think it could be fairly complex to implement. The current approach strikes a better balance between technical design and usability.
You can use |
Beta Was this translation helpful? Give feedback.
and others
Uh oh!
There was an error while loading. Please reload this page.
-
Hi everyone! 👋
We are starting to plan the next major version of oRPC (v2), and we want to build it with your input.
We aim to refine the DX, improve performance, and address architectural limitations. We need to know:
Please drop a comment below with your thoughts, code snippets, or just a +1 on ideas you like. Let's make v2 amazing! 🚀
Beta Was this translation helpful? Give feedback.
All reactions