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

51–60 of 223 posts

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

#51

Post by bborud »

wruza wrote: post #29

Surprised this thread isn’t full of scary RPC stories and SOAP CORBA under your bed at night. Either the wave is gone or it’s just a little early.

I'm not too surprised. Most people for whom TypeScript is an option won't have been exposed to generations of RPCs that fail to deliver simplicity. So it isn't going to be on their radar.

I've been using gRPC and REST'ish+JSON APIs for years now and what I find puzzling is that REST+JSON tends to mean a lot more work, less pleasing code than gRPC, and yet people prefer it. Not because it leads to simpler, better, faster less error prone code (it doesn't. Quite the opposite), but, I think, because people feel they can understand it.

The people over at https://buf.build have been doing a great job trying to tame gRPC btw. The protoc toolchain from Google has been uniquely horrible to work with, but the 'buf' tool from said company has been a real life-saver. Not to mention their Buf Schema Registry, which admittedly I have only used on a few projects so far, but should migrate more projects to.

Though in general, I feel that RPC mechanisms that are too closely tied to a given language are a waste of time. But that's me. tRPC isn't something I'd get into even if I was doing server side TS. It just doesn't seem like a good long term choice.

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

#52

Post by Takennickname »

rwieruch wrote: post #45
thowrasdf23 wrote: post #14

Earlier quoted context omitted.

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

I think it makes people wonder whether rsc are needed, not the libraries

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

#54

Post by pjmlp »

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…

> I've never seen IDL before but I looked up some examples...

Proving my point.

Search for Sun RPC, DCE RPC, XDR.

Take note when they came up, and everything in between until today.

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

#56

Post by hobofan »

worksonmine wrote: post #40
hobofan wrote: post #6

end-to-end (as long as the backend is Node.js)

Does end-to-end have to be agnostic to the backend to you? Do you feel the same way about end-to-end encryption? Would you say "end-to-end encryption as long as the backend is rust/go/c"? Why not, what's the difference? Most projects exist in a ecosystem, and in this case using the same language on both ends makes total sense don't you think? They pull from the same repository, use the same language servers, and run…

Until very recently single-language frontend + backend stacks were not the norm.

As tRPC is in competition with solutions like GraphQL or REST APIs where the backend can be implemented in a big number of languages, I thought that limitation was worth pointing out.

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

#57

Post by zukzuk »

spion wrote: post #53

So what do you do when you decide that you don't want to use JavaScript anymore on either side of tRPC? (switch to something else on the server, or write a native mobile app, etc)

Use TypeScript instead? (semi-joking)

The way I've been approaching this lately is TypeScript on the frontend, then a thing TypeScript layer on the backend (via Deno), with those two pieces connected with tRPC. The real backend guts are in Rust (or whatever), and the backend tRPC layer talks to the Rust stuff with gRPC.

So something like this:

    [(TS web client)  (TS thin backend)]  (Rust service)
This is a bit awkward, but honestly worth it for what you get with tRPC. One thing that took some getting used to is with tRPC the line between "client" and "server" gets blurry, which makes me uncomfortable for all sorts of reasons but in practice works well enough to make it not worth worrying about for now.

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

#59

Post by ushakov »

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…

Garph is like tRPC but for GraphQL: https://garph.dev

For REST APIs there's ts-rest (https://ts-rest.com), zodios (https://www.zodios.org) and Hono (https://hono.dev)

If your team uses multiple languages, there's Fern: https://www.buildwithfern.com

Post reply on HN