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

71–80 of 223 posts

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

#71

Post by tough »

alexdotjs wrote: post #60

Heya! Creator of tRPC here, just wanted to drop by and say thanks for all the love ♥

Hey Alex, I had the luck to learn about tRPC directly from you when working at an open source company that used it for a while.

I quite remember tRPC being the only unknown part of the stack when I started there, and I was a bit scared, but tbh it was pretty easy to pick up and it's an awesome abstraction to make the server of fullstack codebases in typescript.

I always liked GraphQL but if you're working solo it doesn't make that much sense to have the GraphQL api as contract. With external devs a little bit more.

+1 to OpenAPI and being able to generate code, SDK's, docs, automagically.

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

#72

Post by austin-cheney »

bluocms wrote: post #18
austin-cheney wrote: post #4

I am up voting this because its a good idea and you have really nice web site. I wrapped up something like this myself a few weeks ago, so I am in a position to offer some suggestions other people may not think about. The most common mistake I see with RPC, especially WebSockets, using Node.js is that they must be based off of HTTP. My attempt is based upon WebSockets, RFC 6455, where RPC is a generic term for socket…

You can design to be transport agnostic. Then add various transport types: sockets, http, in memory (for testing)…

I don't think that is correct. HTTP is managed by applications, but TCP packets are managed in the OS kernel. That distinction determines your options of approach and how things interact when parsing transport negotiation mechanisms.

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

#73

Post by tough »

aCoreyJ wrote: post #50
Void_ wrote: post #3

Earlier quoted context omitted.

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.

Could you expand on this?

You don't need it, but you certainly can prefer to use it regardless?

Hoping react-server-components trpc gets solved soon

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

#74

Post by cco »

I hadn't heard of tRPC until a developer I was working with raved about it and it just seemed like such an obvious good after I learned about it.

We built a T3 app (tRPC, Next.js, Tailwind, TypeScript, Prisma) together (if you'd like to check it out https://github.com/stytchauth/stytch-t3-example).

Type safe APIs while working in TypeScript is just so helpful.

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

#75

Post by tough »

rwieruch wrote: post #23
ianlevesque wrote: post #15

Earlier quoted context omitted.

For what it’s worth I have never heard of RSC and it’s not googleable. Have a link?

React Server Components. Sorry, I edited the comment above.

I believe the hype of RSC it's just a natural part of it being a NextJS/React core feature from those teams, and not a 3rd party package like tRPC.

React and Angular won by being backed by FAANG first, people loves to choose FOSS backed by big names for some reason gives them pause

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

#76

Post by c-hendricks »

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…

This works quite well actually:

https://github.com/mikew/transmission-material-ui/blob/maste...

https://github.com/mikew/transmission-material-ui/blob/maste...

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

#77

Post by cjblomqvist »

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…

The thing that always strikes me is that verbs and paths are pretty tiny details (and also easy to abstract away using endpoint consumer generation libs) - then what else do you really get compared to your normal average web api? You still need to perform everything in each call to the backend anyway.

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

#78

Post by tough »

zukzuk wrote: post #65
JSavageOne wrote: post #44

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.

tRPC is not at all intended to ever be a public API, the way REST or GraphQL is. It's meant to be a tight, private connection between your client and your server. If you use tRPC in your stack but want a public API, you will almost certainly need to build that out separately, via traditional REST, or GraphQL, or maybe gRPC. This feels all kinds of wrong initially, and there are some obvious and not so obvious disadva…

At an open source company I worked briefly, we used tRPC, and I was tasked with making the Enterprise API,

We went with a nextjs app, abstracted away our tRPC routers into a package and our monorepo, and used tRPC different routers both from our webapp and the API apps.

This works great!

You end up not repeating your logic all over the place, and make thin wrappers on your nextjs api endpoints or whatever to handle the differences between implementations

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

#79

Post by c-hendricks »

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

Earlier quoted context omitted.

> 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…

Hm, yeah I don't think we had similar experiences with GraphQL then

> you infer client types from server definitions without including actual server code into the client

Our types are generated into their own package, so there's no chance of importing server code.

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

#80

Post by Trufa »

alexdotjs wrote: post #60

Heya! Creator of tRPC here, just wanted to drop by and say thanks for all the love ♥

Hey dude! We met in the prisma conf in Berlin a couple of years ago and had some beers after with an Aussie dude, since then I’ve used nothing but tRPC in all of my projects and couldn’t be happier, thanks for the hard work!
Post reply on HN