Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

tRPC – Build and consume typesafe APIs without schemas or code generation

trpc.io

Post reply on HN
Print view View original

41–50 of 223 posts

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#41

Post by chaos_emergent »

scriptsmith wrote: post #13
jitl wrote: post #7

We’ve use an API style similar to tRPC at Notion, although our API predated tRPC by 4 years or so. You can build this kind of thing yourself easily using Typescript’s mapped types, by building an object type where the keys are your API names, and the values are { request, response } types. Structure your “server” bits to define each API handler as a function taking APIs[“addUser”][“request”] and returning Promise . T…

Is there some trick to doing validation of request data using this process? That's a valuable part of using something like tRPC, JSON Schema + type generation, zod, etc.

Deepkit is a fantastic solution for this. It uses a compilation step to inject metadata about types into plain JS.

https://deepkit.io/

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#42

Post by pimpl »

Void_ wrote: post #3
pimpl wrote: post #2

I've used tRPC and Next.js for a couple of personal projects and it's been a great experience. Hard to beat on iteration speed, especially when used with a pre-configured template like Create T3 App: https://create.t3.gg/ .

Does it now work properly with Next 13 and server components?

I think patterns and best practices are still yet to be figured out. I believe you can create caller in a server component and it should work (https://trpc.io/docs/server/server-side-calls#create-caller), but the pages router appears to be a battle-tested solution.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#43

Post by blascsi »

I've just started using tRPC, and I'm in love with it so far! I use GraphQL at work, but I always felt like the boilerplate is too much for my hobby projects, and I wasn't really happy with the code-first frameworks that I could find (especially with the ones that support proper Relay integration). Thanks a lot for the creators! Also if anyone is enticed by this, I highly recommend trying it out!

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#44

Post by JSavageOne »

I've personally been using ts-rest for my projects, which is traditional REST but allows one to autogenerate types and API docs from a zod schema.

tRPC seems cool, but seems riskier to go with an alternative to REST or GraphQL, especially if you intend to make your API public and/or have multiple consumers of your API.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#45

Post by rwieruch »

thowrasdf23 wrote: post #14
candiddevmike wrote: post #11

Earlier quoted context omitted.

What does the Royal Shakespeare Company have to do with RPC? (or please define/link acronyms folks may not know!)

I'm guessing React Server Components which is apple to oranges with tRPC.

it is. But RSC make many library authors and maintainers question whether their library is still needed in a RSC world and if so how they can support it. Same story with tRPC https://github.com/trpc/trpc/issues/3297

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#46

Post by c-hendricks »

jensneuse wrote: post #22

I'm a big fan of tRPC. It's amazing how it pushed TypeScript only stacks to the limit in terms of DX. Additionally, it made the GraphQL community aware of the limitations and tradeoffs of the Query language. At the same time, I think tRPC went through a really fast hype cycle and it doesn't look like we're seeing a massive move away from REST and GraphQL to RPC. That said, we see a lot of interest in RPC these days a…

> it made the GraphQL community aware of the limitations and tradeoffs of the Query language

Could you expand on that? Our graphql types are generated from our federated schema whenever it changes, and response types for queries / mutations are generated whenever you save a file.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#47

Post by bborud »

nerdponx wrote: post #38
pjmlp wrote: post #28

RPC IDL keeps being reinvented by those that fail to understand where we came from. Pop fashion industry.

OpenAPI, JSON-RPC, and JSONSchema have existed for a pretty long time now. The industry has more or less standardized on JSON for data interchange and parsers/generators for JSON abound in every programming language, so it makes sense to do all this stuff with JSON. I've never seen IDL before but I looked up some examples and it does seem useful for RPC calls. But I'm not exactly eager to switch, it looks like it's m…

IDL in this context is a generic term that stands for Interface Description Language.

I think you kind of made his point for him.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#48

Post by jitl »

chaos_emergent wrote: post #41
scriptsmith wrote: post #13

Earlier quoted context omitted.

Is there some trick to doing validation of request data using this process? That's a valuable part of using something like tRPC, JSON Schema + type generation, zod, etc.

Deepkit is a fantastic solution for this. It uses a compilation step to inject metadata about types into plain JS. https://deepkit.io/

Deepkit looks really cool, but it’s so complex on the inside and leverages a forked/patched Typescript and requires full typecheck before emit.

What happens if the Deepkit guy retires? What if I want to run my code without waiting for 11 minutes of typechecking? What if there’s a bug somewhere in there?

There’s way too much risk for me to consider Deepkit for production.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#49

Post by jensneuse »

c-hendricks wrote: post #46
jensneuse wrote: post #22

I'm a big fan of tRPC. It's amazing how it pushed TypeScript only stacks to the limit in terms of DX. Additionally, it made the GraphQL community aware of the limitations and tradeoffs of the Query language. At the same time, I think tRPC went through a really fast hype cycle and it doesn't look like we're seeing a massive move away from REST and GraphQL to RPC. That said, we see a lot of interest in RPC these days a…

> it made the GraphQL community aware of the limitations and tradeoffs of the Query language Could you expand on that? Our graphql types are generated from our federated schema whenever it changes, and response types for queries / mutations are generated whenever you save a file.

With tRPC and similar frameworks, you infer client types from server definitions without including actual server code into the client. As much as I like GraphQL, one thing that IDEs really suck at is recognizing when generated code changes. E.g. with Jetbrains IDEs it sometimes takes forever until a change to the generated code is actually picked up by intellisense. VSCode is a little bit better regarding this. When you infer types in tRPC style, this whole problem is gone. You can even jump between the client usage and the server implementation. That said, this is not without a cost. Large Typescript codebases can slow down the typescript autocompletion and this approach only works best when both client and server are written in typescript and ideally in the same codebase.

Re: tRPC – Build and consume typesafe APIs without schemas or code generation

#50

Post by aCoreyJ »

Void_ wrote: post #3
pimpl wrote: post #2

I've used tRPC and Next.js for a couple of personal projects and it's been a great experience. Hard to beat on iteration speed, especially when used with a pre-configured template like Create T3 App: https://create.t3.gg/ .

Does it now work properly with Next 13 and server components?

In server components you can just await in the component itself so you don't need a solution like tRPC.
Post reply on HN