🚀 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.
-
|
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.
-
|
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.
-
|
codegen. types generation to use in frontend props. |
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
-
|
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.
-
|
I'm fan of Redux so RTKQuery integration as similar as React Query. |
Beta Was this translation helpful? Give feedback.
-
|
Use srcx for adapters |
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.
-
|
Returning custom headers and status codes would be great |
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.
-
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.
-
|
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.
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