🚀 Road to oRPC v2: Call for Ideas, Features & Feedback #1293
Replies: 39 comments 69 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.
-
|
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.
-
|
Stabilize ArkTypeToJsonSchemaConverter. |
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.
-
|
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 believe Pino should work in cd workers pinojs/pino#2035 |
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.
-
|
The input/output detailed mode should be able to type the parameter for const detailedMode = os.route({
path: '/ping/{name}',
method: 'POST',
inputStructure: 'detailed',
})
.input({
params: z.object({ name: z.string() }),
query: z.object({ search: z.string() }),
body: z.object({ description: z.string() }).optional(),
headers: z.object({ 'x-custom-header': z.string() }),
})let me know if this possible or not |
Beta Was this translation helpful? Give feedback.
-
|
It's hard man, because we allow define .route after .input and I want keep oRPC simple as possible. |
Beta Was this translation helpful? Give feedback.
-
|
Nowhere in the docs does it say that |
Beta Was this translation helpful? Give feedback.
-
|
What about |
Beta Was this translation helpful? Give feedback.
-
|
The pojo as the detailled input instezd of a whole schema is kinda my suggestion 5. |
Beta Was this translation helpful? Give feedback.
-
|
yeah that could be a great idea @unnoq! |
Beta Was this translation helpful? Give feedback.
-
|
tough ask because you've done such a good job with orpc already :)
|
Beta Was this translation helpful? Give feedback.
-
|
Angular Resource integration, similar to the Tanstack Query integration. Resource is based on the angular's new "Signal" reactivity API, which integrates with the angular components lifecycle and rendering, including automatic abort and reloads. We're currently using it like this: import { Component, inject, input, resource } from '@angular/core';
@Component({
//...
})
export class EditOrganizationComponent {
orpc = inject(SmartOrpcClientService);
snackBar = inject(SnackbarService);
readonly id = input.required<string>();
readonly organization = resource({
params: () => ({ id: this.id() }),
loader: async ({ params }) => {
const { error, data } = await this.orpc.safeClient.organization.byId(
Number(params.id),
);
if (error) {
this.snackBar.handleOrpcError(error);
return;
}
return data;
},
});
//...
} |
Beta Was this translation helpful? Give feedback.
-
|
I am creating an n8n workflow that needed to interact with my api written with orpc. |
Beta Was this translation helpful? Give feedback.
-
|
About mcp: https://github.com/Jacse/trpc-mcp (trpc has this) |
Beta Was this translation helpful? Give feedback.
-
Beta Was this translation helpful? Give feedback.
-
|
Honestly, it already feels like oRPC gives me everything! I'd ask for Standard JSON Schema support, but I imagine that's not even a breaking change. More in-depth documentation in general is also always welcome! |
Beta Was this translation helpful? Give feedback.
-
|
Adding an oRPC Skill would be great. |
Beta Was this translation helpful? Give feedback.
-
|
What is the usecase for skills in orpc? |
Beta Was this translation helpful? Give feedback.
-
|
it would help ai agents understand & utilize the library better |
Beta Was this translation helpful? Give feedback.
-
|
I'm fan of Redux so RTKQuery integration as similar as React Query. |
Beta Was this translation helpful? Give feedback.
-
|
Related: #345 |
Beta Was this translation helpful? Give feedback.
-
Thanks tell me about it! 😊 |
Beta Was this translation helpful? Give feedback.
-
|
Use srcx for adapters |
Beta Was this translation helpful? Give feedback.
-
|
oRPC always support it through |
Beta Was this translation helpful? Give feedback.
-
|
My main annoyance with orpc is the
Here's what my code currently looks like: import { os } from "@orpc/server"
const osWithContext = os.errors(...).$context<RPCContext>()
export const middleware = osWithContext.middleware
export const osWrapper = os.use(checkUserAuthentication)The expectation is then that people use osWrapper everywhere instead e.g. The code I would like to write is this: import { initORPC } from "@orpc/server"
export const os = initORPC
.errors(...)
.$context<RPCContext>()
.use(...)That way, there's only one way to define a route or middleware - import the People accidentally using the Note another limitation is that you can't use |
Beta Was this translation helpful? Give feedback.
-
|
@ryanxcharles this version very like tRPC version: export const initedOS = os
.errors(...)
.$context<RPCContext>()
export const middleware = initedOS.middleware.bind(initedOS)
export const protectedProcedure = initedOS.use(...) |
Beta Was this translation helpful? Give feedback.
-
|
that's the code in my original comment. It's problematic for these reasons:
import { initORPC } from "@orpc/server"
export const os = initORPC
.errors(...)
.$context<RPCContext>()
.use(...)
// Use os.middleware and os.route as normalIs there a reason you're against that, or prefer the usage as you wrote it |
Beta Was this translation helpful? Give feedback.
-
|
@tanishqkancharla Please read my first comment, it contains everything. |
Beta Was this translation helpful? Give feedback.
-
|
@tanishqkancharla If its readability you are concerned with you could create a file like import { os } from '@orpc/server'
export initORPC = () => osnow you can do: import { initORPC } from "./orpc"
export const os = initORPC()
.errors(...)
.$context<RPCContext>()
.use(...)
// Use os.middleware and os.route as normal |
Beta Was this translation helpful? Give feedback.
-
|
You can ban the |
Beta Was this translation helpful? Give feedback.
-
|
Returning custom headers and status codes would be great |
Beta Was this translation helpful? Give feedback.
-
|
OpenAPIHandler already supports it. |
Beta Was this translation helpful? Give feedback.
-
|
Procedure inherence or procedure override / extend. Use case: I would like to make the input validation more restrictive. I have created a procedure that I use in multiple ways: exposed via API endpoints and called directly. However, for one specific API, I need stricter input validation. |
Beta Was this translation helpful? Give feedback.
-
|
Hi @unnoq, Regarding Architectural Limitations, I want to highlight a critical design choice in the current adapters that I believe is a general anti-pattern and should be refactored in v2. This has already been mentioned here:
The Pain Point: Eager Response OwnershipCurrently, Looking at Why this is a General Architectural Anti-PatternThis is not just a NestJS issue; it is a Middleware/Integration Anti-Pattern often called "Response Hijacking."
Impact on Fastify & Express The Fix / Suggestion for v2Decouple "Execution" from "Transmission." The Core Handlers should return a
This shifts the responsibility of sending the response to the "Adapter Layer" or the host framework.
This small inversion of control transforms |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for your detailed suggestions and the proposed architecture. However, I still believe the current approach is more robust.
If the points above are still not convincing, please show this in more concrete terms. Specifically, how would the oRPC API look under the new design when integrating with |
Beta Was this translation helpful? Give feedback.
-
|
might not be following correctly, but is the friction we ran into in #954 related to this as well? |
Beta Was this translation helpful? Give feedback.
-
|
@marbemac v2 will built in support octet streaming - so we do not need touch at adapter layer - just a simple plugin that convert |
Beta Was this translation helpful? Give feedback.
-
If this type complexity can't be simplified, some additional documentation for these kind of situations would be great. |
Beta Was this translation helpful? Give feedback.
-
|
I may get a lot of things wrong here, so apologies in advance - Next.js is WinterTC compliant. Other frameworks (with different scope) such as Elysia are also WinterTC compliant and can replace all Next.js API routes. I wonder if we could have something similar with oRPC's OpenAPI? So all routes get handled by oRPC essentialy. |
Beta Was this translation helpful? Give feedback.
-
|
oRPC can safely run in any WinterTC compliant runtime, but internally oRPC make it simpler and in v2 it will power as any other frameworks |
Beta Was this translation helpful? Give feedback.
-
|
Awesome! |
Beta Was this translation helpful? Give feedback.
-
|
A small type-safe suggestion for v2 is better type safety for the oRPC clients. createORPCClient(new OpenAPILink(contract, { url: 'http://localhost:8080' }))This code produces a createORPCClient<ContractRouterClient<typeof contract>>(contract, { url: 'http://localhost:8080' }))Having to manually provide the generic is always a possible case of bugs - as happened to me now by copy&pasting some stuff. |
Beta Was this translation helpful? Give feedback.
-
|
Actually, the two implementations are equivalent and already support. const client: ContractRouterClient<typeof contract> = createORPCClient(link)
// vs
const client = createORPCClient<ContractRouterClient<typeof contract>>(link) |
Beta Was this translation helpful? Give feedback.
-
|
Yes, but in both cases you must do manually typing because TypeScript can't infer the correct type automatically - which you mostly do when developing TS. Manual typing is not done so much. When writing typical typescript code it does not work: const client = createORPCClient(link) |
Beta Was this translation helpful? Give feedback.
-
|
I think I can make it auto infer in case your link has a |
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