What are your thoughts on tRPC.io?

[aaronvg]

I haven't dove into tRPC quite yet (I'm checking it out now) but would be curious to hear what you think of that project!

[RobinTail]

Hello @aaronvg ,

I did not use tRPC myself, but once I got familiar with its concept.
As far as I know tRPC is awesome and well developed library that definitely make sense to consider.

Libraries have similar goals, but there is a number of differences.
There are some features in my library that I find beneficial.

I like the description of routes in my library more.
I also like that no special client needs to be installed on the frontend, just importing types and using them to assign requests and responses is enough.

Although it is possible that the tRPC solution is more plug-and-play.
I'm not sure, you can try both and gain your own opinion.

I'd be curious, please let me know :)

[aaronvg]

I did end up trying trpc.io and ended up migrating to it since we do have a react app and it did seem like it solved a lot of our problems. It was nice to be able to export a single client type rather than each endpoint's types individually.

Anyway thanks for sharing your library, definitely has other usecases.

I agree the routing in your lib is much cleaner looking

[RobinTail]

Great, @aaronvg . Thank you for sharing.
I will try to improve exporting types.

[RobinTail]

@aaronvg , I'd like to inform you that I've improved exports of API types to the frontend.
There is a new feature — Client generation — released in version 6.1.0.

[aaronvg]

Wow, looks very clean!! Thank you, I will check this out again!

[HardCoreQual]

tRPC is very nice for fullstack monorepo, related to frontend client think the main difference is that tRPC infer the structure of router with input & ouput types for each endpoint, resulted type is imported in frontend where this type structure can be used in client for specifying available routes and input, output data
express-zod-api how I understand requires client generation, and will necessit rerun generate client after each change in backend

think for creating this type is enough

const routing = {
  endpoint,
};

type EndpointToInputOutput<T extends AbstractEndpoint> = {
  input: z.input<ReturnType<T['getInputSchema']>>;
  output: z.output<ReturnType<T['getOutputSchema']>>;
};

// of course here need implement also for methods
type RecursiveExtractTypes<T extends Routing> = {
  [P in keyof T]: T[P] extends Routing
    ? RecursiveExtractTypes<T[P]>
    : T[P] extends AbstractEndpoint ? EndpointToInputOutput<T[P]> : never
};
// and possible that for frontend client will be more util structure like {  '/:app/file/upload': { post: { input: any, output: any } }  } 

export type BackendStructure = RecursiveExtractTypes<typeof routing>;

more complex task is to write frontend client that will use this imported type

but also in case with tRPC this client have query and mutation instead of standard restapi

[RobinTail]

@HardCoreQual , the type you offering you may find in the previous major version of the library (6.x).
However, it's not so easy, since the actual type of the endpoint response is controlled by ResultHandler, the entity that is being connected to the EndpointsFactory before the Endpoint is created. This design makes easier to create endpoints, but it makes the final type of the endpoint's response to have kinda nested generic type or Monad, that is not supported well in the currently available Typescript.
I used to keep some hacks for that upto the version 6, but then I made a decision to go with the client types generator instead as the more straightforward approach.
You can try version 6 or you can just include the client types generation into your CI/CD process.